Subject: [P2PSIP] dSIP and whether to use SIP as th epeer protocol

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2007 12:02:22 -0400

I read through draft-bryan-p2psip-dsip-00.txt. This draft was very 
helpful to me, since it has thoroughly convinced me that SIP should NOT 
be used as the peer protocol. I believe dSIP is a completely 
inappropriate SIP extension, for reasons which I will describe below. 
Furthermore, I believe that p2psip introduces some important design 
considerations different from SIP, making SIP a poor match. Lastly, I'd 
like to discuss how the argument that using SIP solves NAT traversal is 
completely bogus.

Inappropriateness of SIP
------------------------

The dSIP protocol is an inappropriate SIP extension for several reasons.

1. Inappropriateness of REGISTER

Firstly, its usage of REGISTER is a substantial deviation from the 
semantics of RFC3261. Architecturally, this is because p2psip really 
changes the entire notion of registration; it removes the concept of a 
'domain' which has ownership over a set of identifiers, for which it is 
authoritative. In regular SIP, the domain has control over which 
identifiers are valid in the domain, what entities have ownership over 
those identifiers and therefore are authorized to register them, and has 
the ability to control whether those identifiers remain valid. 
Furthermore, logically there is a single registrar for each domain; 
physically they may be separated, but this is really an 'internal' 
design approach made entirely by the domain that owns the registrar, and 
would be invisible to outsiders. Every single one of these assumptions 
changes with p2psip. With p2psip, there is a concept that is similar to 
SIP registration, but because these assumptions hold, the REGISTER 
semantics have changed.

This manifests itself in several places. p2psip uses REGISTER for (1) 
registering a peer to the network, (2) registering resources into the 
DHT, (3) querying the DHT. The dSIP protocol requires the 'registrar' to 
figure out which of these operations are being performed and then 
describe different semantics for each. This determination is based on 
presence and absence of fields in the specification. It is not allowed 
for an extension to make fundamental changes in the semantics of request 
processing based on that extension. And indeed, that is what happens 
here. Peer joins and resource entries are fundamentally different 
operations.

p2psip requires a change in the fundamental authorization decision that 
a registrar would make. dSIP changes the rules on third party 
registrations, for example, something whose meaning is fundamentally 
different here.

p2psip changes the rules on construction of the To and From URI in 
REGISTER. Now, the IP address is the meaningful identifier - the user 
part is empty and there is no domain. With such a change, a 'registrar' 
cannot follow the processing of RFC 3261 since the fundamental 
identifiers and their meaning have changed.

As another example, the constrains on p2psip basically require that, for 
peer registration, the To, From and Contact all must contain the peer 
ID. In normal SIP, these can all be different since they have different 
semantics. In p2psip, they have to all be the same. This indicates that 
you have made a change in the semantics of REGISTER.

2. Inappropriate extensions to URI

The dSIP draft proposes some new extensions to SIP URI, adding a hash 
identifier and introducing constraints on the contents of both the user 
part and the domain part. I believe these are both problematic.

Firstly, for peer IDs, the hash value is a direct function of the 
hostpart of the URI. Normally, URI parameters represent different 
information than what is already in the URI. Not so here. This means 
that you raise some new error cases, when the hash doesn't match the IP 
address. Avoiding these is why protocols typically have the requirement 
of doing the same thing only once.

More importantly perhaps, the peer IDs *require* that the user part of 
the URI be empty. This is a consequence of this fundamental issue that 
we don't have domains here and the entire notion of a use identifier 
within the scope of a domain is not meaningful. It is not an appropriate 
use of SIP identifiers to *require* that, for a particular domain, the 
user part cannot be used. This is a warning that something is amiss here.

Resource-IDs are different in that they do have a user part; but this is 
just as worrisome. Both peer ID and resource IDs are both SIP URI, yet 
they have very different requirements for their construction. I think 
this is a warning that SIP URI are not the right thing here, and that 
the resource is simply DIFFERENT from the resource ID or peer ID, which 
are both names within a hashspace. One is NOT an extension of the other.

3. Inappropriate responses

dSIP makes use of several existing response codes, but almost all of 
them are inappropriate usages of those response codes. Lets take a look:

488: This is returned by a peer when a join is attempted and the DHT 
algorithm is not supported by the network. 488 does not have this 
semantic. It is about media incompatibility and it is inappropriate to 
use this for DHT errors.

493: This is used to signal that the hash is a mismatch to the IP 
address in a peer ID. This is not at all the semantic of this error 
code, which refers to the inability to decipher an S/MIME body. 
Consequently, the usage of this response code here is inappropriate.

302 (with expires): This is used to signal several redirection cases. 
However, in normal SIP the entity that generates the 302 is 
authoritative for the resource and therefore can say with some 
confidence that it moved and for how long. However, here, the location 
in the p2p network is a dynamic function of the distribution of the hash 
table. Consequently, it is not possible to include expiration values.

501/5xx: This response is used by a peer receiving a peer query, when 
that peer doesn't support p2p, it genreates a 5xx. Of course, a non-p2p 
entity won't know to do this so it doesn't make sense.

4. Implied Proxy-Require

dSIP uses peers as either proxy or redirect servers to forward a 
REGISTER query to the right target. However, the spec requires every 
proxy in the chain to support the p2p extensions, and for p2p peers to 
reject regular SIP extensions. This is stated in Section 7.2.2 here 
through these two requirements:

    In the event a P2P peer receives a non-P2P
    request, it SHOULD reject it with a message such as 421 Extension
    Required.

    In the event
    that the peer does not support P2P extensions, it MUST reply with a
    5xx class response such as 501 Not Implemented.

The first of these implies that p2p REGISTER queries need to be rejected 
by any non p2p proxies, and consequently this is effectively 
Proxy-Require. The latter requirement is even stronger - it is saying 
that p2p proxies can't be normal proxies. We've never had such a 
requirement in SIP from any extension. It will create a complete 
bifurcation in these two protocols, and makes it very clear to me that 
this is not SIP.

Beyond the inappropriateness of SIP to this task, there are certain 
other design objectives that make SIP a poor choice here:

1. Other p2p operations

In addition to the operations of peer joins, resource queries and peer 
queries, a full p2p network will require other functions that are very 
poor matches for sip. In particular, it will require transfer of p2p 
table contents: A joining peer will need to copy the part of the hash 
table which it now owns. SIP is a poor transfer protocol. The draft 
suggests a series of REGISTER queries for the transfer, but this doesn't 
work since the entity joining doesn't know what resources to ask for. 
Some kind of bulk transfer method is required. SIP cannot be used for 
bulk transfer [RFC 4485, Section 3.1]. Consequently, SIP will not meet 
this requirement.

There may be other functions required in p2p table maintenance; why 
should be be constrained to what SIP is good at?

2. Usability for other non-SIP applications

I had understood that our objective in p2psip was to build a p2p 
protocol that worked well for SIP, and not try to solve the general p2p 
problem. However, this is NOT the same thing as saying that we should 
build a p2p protocol that can ONLY be used for SIP! That is the 
consequence of using dSIP - this will only ever be useful for this 
application. I would rather define a p2p protocol that is targeted at 
our requirements, and then future groups or applications can consider 
extensions to meet their requirements if a need arises.

3. Bandwidth

p2p networks are ideal in that they scale extremely well, without 
requiring centralized resources. However, this comes with two penalties. 
First, the latency for processing a lookup is increased (grows 
logarithmically with the size of the network) and the overall bandwidth 
required in the system increases.

If you take a normal SIP client that is a participant in a 10M node SIP 
network, and measure the traffic on its access link towards the network, 
the traffic (considering just signaling) is not a function of the 
network size and is relatively low. With a p2p network, the node must 
process p2p network queries unrelated to its own calls, which I believe 
scales with logN/N. Indeed, a frequent 'complaint' about p2p networks is 
that it 'hogs the network'.

Consequently, I think there is a real need to minimize the expense of 
this connectivity, in terms of bandwidth. Very little of SIP is actually 
needed in the peer protocol. You will be paying for lots of bytes to 
transfer data you don't need. I would much rather design a tiny little 
binary protocol that is highly bandwidth optimized, to address the real 
issue and to address perception that this protocol is expensive.

A text protocol would be a poort choice here, a text protocol with tons 
of extra fields you don't need is an even worse choice.

4. CPU

Similar to the bandwidth issue, p2p protocols require CPU processing 
that scales as logN/N. Again the perception is that p2p networks keep my 
machine busy. I would therefore strive for a trivial protocol where you 
can demonstrate the ability to support tremendous amount of processing 
with little cost. SIP is a poor choice here, since it is fairly complex 
in parsing and overall processing. For general signaling, that tradeoff 
is a good one because the need for generality in signaling. However, 
that generality is not needed for a p2p mesh protocol and consequently 
costs you CPU cycles for no benefit.

5. Separation of interests

I think this will be hard for people to implement. The reason is that 
most folks with an existing SIP stack will need to heavily muck with 
that stack to insert these extensions. It would be much nicer to 
separate the SIP pieces from the DHT maintenance. So, I could go an 
implement a separate p2p protocol in a separate library (or indeed use 
something that exists today to play around with it), and simply 'plug 
in' the DHT computation, which ultimately converts an AOR to an IP 
address, as an alternative to RFC 3263. Indeed, many implementations 
already support pluggable mappings, so you'd just need to drop this p2p 
library in a wrapper and voila - you have p2psip.

Finally, I'd like to debunk a myth. dSIP states in Section 4:

    Because dSIP uses conventional SIP messages, the mechanisms used for
    NAT traversal in SIP, including STUN [4], TURN [17], and ICE [5] are
    reused, as explained in NAT Traversal for dSIP [6].

There is this belief that the converse is true; that you need to use SIP 
to reuse STUN, TURN and ICE. This is false.

STUN and TURN are not tied to ANY PROTOCOL. You can use both of those 
equally well, without any changes to STUN or TURN, for a brand new 
binary protocol as equally well as you could with SIP.

ICE cannot be used with just any protocol, but it is not limited to SIP. 
It is useful in any OFFER/ANSWER protocol. This does not require SIP. 
You could instead define a new p2p binary protocol that uses the O/A 
model for connections, and specify an alternate syntactic encoding for 
the SDP, whether it is a binary compression (not recommended), or simply 
a binary representation of only those fields that are relevant. This 
would allow you to completely reuse ICE without dealing with any of the 
overhead that the rest of SDP brings with it.

I'm not objecting to the basic flow of 
draft-matthews-p2psip-dsip-nat-traversal-00.txt, which is actually very 
clever I think; rather, I'm saying you can accomplish this same approach 
using ICE, STUN and TURN, but do it with a custom protocol tuned to p2psip.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 20 Mar 2007 17:21:59 +0100

Obviously I'll have a lot more to say once I have time to digest, but...

> to reuse STUN, TURN and ICE. This is false.

No such statement made, actually. The point is that you can reuse
everything as is, without new work defining how to use it with the new
protocol. It certainly doesn't imply you can't make something else
work with ICE, but as you point out, you have to define offer/answer
like mechanism in this new protocol and a number of other things (and
I'll point out that once you locate the remote party, you STILL need
to do ICE again for the now different SIP ports)

Looks like an awful lot of reinvent a new protocol work. Inventing new
protocols might be fun, but not covinced it is needed.

More to follow, since I think many of the other statements aren't quite right.

David (as individual and SIP as Peer Protocol supporter...)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Eric Cooper" <[email-masked]>
Date: Tue, 20 Mar 2007 13:08:19 -0400

[snip]

> draft-matthews-p2psip-dsip-nat-traversal-00.txt, which is actually 
> very clever I think; rather, I'm saying you can accomplish this same 
> approach using ICE, STUN and TURN, but do it with a custom protocol 
> tuned to p2psip.
>
[EC] I think the requirements on the Peer Protocol to allow it to 
traverse NATs are relatively few, actually.  It should do stuff like 
re-use the same addresses and ports for send/recv, send responses to the 
same address/port from which the requests were received, re-use 
connections, etc.  The mechanisms for these types of operations are 
well-known for SIP, but I'm sure any number of other protocols (or a new 
protocol) can easily do the same things.

The more interesting part (IMO) is how to initially establish the peer 
protocol connection through a NAT.  draft-matthews-bootstrap-mechanisms 
discusses this problem in a general way, without assuming that the Peer 
protocol is SIP.  Very briefly, it says that SIP is a good protocol for 
establishing peer protocol sessions. 
draft-matthews-p2psip-dsip-nat-traversal is, in some sense, an 
application of the ideas from the bootstrap draft to the dSIP system. 
As David points out, much of the work can be re-used from SIP, though 
the use of "application/sip" in the m= line may require a bit of new 
work.

Best Regards,

Eric.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Mar 2007 18:33:10 +0100

I think a large part of the original motivation of using SIP here was  
to quickly get to a proof of concept that the P2P SIP problem was an  
engineering decision not an research problem - this was needed to  
form a WG  - I think dSIP nicely proves that.

However, regardless of if we could get SIP to work, the questions is  
to me is what would be the optimal properties of an DHT update  
protocol. Very low CPU process of message is very high on my list  
because that is the place where nearly all communications systems I  
am familiar with end up being bottlenecked.

Cullen <with my individual hat on>

On Mar 20, 2007, at 5:02 PM, Jonathan Rosenberg wrote:

> helpful to me, since it has thoroughly convinced me that SIP should  
> NOT be used as the peer protocol. I believe dSIP is a completely  
> inappropriate SIP extension, for reasons which I will describe  
> below. Furthermore, I believe that p2psip introduces some important  
> design considerations different from SIP, making SIP a poor match.  
> Lastly, I'd like to discuss how the argument that using SIP solves  
> NAT traversal is completely bogus.
>
> Inappropriateness of SIP
> ------------------------
>
> semantics of RFC3261. Architecturally, this is because p2psip  
> really changes the entire notion of registration; it removes the  
> concept of a 'domain' which has ownership over a set of  
> identifiers, for which it is authoritative. In regular SIP, the  
> domain has control over which identifiers are valid in the domain,  
> what entities have ownership over those identifiers and therefore  
> are authorized to register them, and has the ability to control  
> whether those identifiers remain valid. Furthermore, logically  
> there is a single registrar for each domain; physically they may be  
> separated, but this is really an 'internal' design approach made  
> entirely by the domain that owns the registrar, and would be  
> invisible to outsiders. Every single one of these assumptions  
> changes with p2psip. With p2psip, there is a concept that is  
> similar to SIP registration, but because these assumptions hold,  
> the REGISTER semantics have changed.
>
> This manifests itself in several places. p2psip uses REGISTER for  
> (1) registering a peer to the network, (2) registering resources  
> into the DHT, (3) querying the DHT. The dSIP protocol requires the  
> 'registrar' to figure out which of these operations are being  
> performed and then describe different semantics for each. This  
> determination is based on presence and absence of fields in the  
> specification. It is not allowed for an extension to make  
> fundamental changes in the semantics of request processing based on  
> that extension. And indeed, that is what happens here. Peer joins  
> and resource entries are fundamentally different operations.
>
> p2psip requires a change in the fundamental authorization decision  
> that a registrar would make. dSIP changes the rules on third party  
> registrations, for example, something whose meaning is  
> fundamentally different here.
>
> REGISTER. Now, the IP address is the meaningful identifier - the  
> user part is empty and there is no domain. With such a change, a  
> 'registrar' cannot follow the processing of RFC 3261 since the  
> fundamental identifiers and their meaning have changed.
>
> As another example, the constrains on p2psip basically require  
> that, for peer registration, the To, From and Contact all must  
> contain the peer ID. In normal SIP, these can all be different  
> since they have different semantics. In p2psip, they have to all be  
> the same. This indicates that you have made a change in the  
> semantics of REGISTER.
>
> The dSIP draft proposes some new extensions to SIP URI, adding a  
> hash identifier and introducing constraints on the contents of both  
> the user part and the domain part. I believe these are both  
> problematic.
>
> information than what is already in the URI. Not so here. This  
> means that you raise some new error cases, when the hash doesn't  
> match the IP address. Avoiding these is why protocols typically  
> have the requirement of doing the same thing only once.
>
> More importantly perhaps, the peer IDs *require* that the user part  
> of the URI be empty. This is a consequence of this fundamental  
> issue that we don't have domains here and the entire notion of a  
> use identifier within the scope of a domain is not meaningful. It  
> is not an appropriate use of SIP identifiers to *require* that, for  
> a particular domain, the user part cannot be used. This is a  
> warning that something is amiss here.
>
> Resource-IDs are different in that they do have a user part; but  
> this is just as worrisome. Both peer ID and resource IDs are both  
> SIP URI, yet they have very different requirements for their  
> construction. I think this is a warning that SIP URI are not the  
> right thing here, and that the resource is simply DIFFERENT from  
> the resource ID or peer ID, which are both names within a  
> hashspace. One is NOT an extension of the other.
>
> dSIP makes use of several existing response codes, but almost all  
> of them are inappropriate usages of those response codes. Lets take  
> a look:
>
> 488: This is returned by a peer when a join is attempted and the  
> DHT algorithm is not supported by the network. 488 does not have  
> this semantic. It is about media incompatibility and it is  
> inappropriate to use this for DHT errors.
>
> 302 (with expires): This is used to signal several redirection  
> cases. However, in normal SIP the entity that generates the 302 is  
> confidence that it moved and for how long. However, here, the  
> location in the p2p network is a dynamic function of the  
> distribution of the hash table. Consequently, it is not possible to  
> include expiration values.
>
> 501/5xx: This response is used by a peer receiving a peer query,  
> when that peer doesn't support p2p, it genreates a 5xx. Of course,  
> a non-p2p entity won't know to do this so it doesn't make sense.
>
> 4. Implied Proxy-Require
>
> REGISTER query to the right target. However, the spec requires  
> every proxy in the chain to support the p2p extensions, and for p2p  
> peers to reject regular SIP extensions. This is stated in Section  
> 7.2.2 here through these two requirements:
>
> The first of these implies that p2p REGISTER queries need to be  
> rejected by any non p2p proxies, and consequently this is  
> effectively Proxy-Require. The latter requirement is even stronger  
> - it is saying that p2p proxies can't be normal proxies. We've  
> never had such a requirement in SIP from any extension. It will  
> create a complete bifurcation in these two protocols, and makes it  
> very clear to me that this is not SIP.
>
>
> In addition to the operations of peer joins, resource queries and  
> peer queries, a full p2p network will require other functions that  
> are very poor matches for sip. In particular, it will require  
> transfer of p2p table contents: A joining peer will need to copy  
> the part of the hash table which it now owns. SIP is a poor  
> transfer protocol. The draft suggests a series of REGISTER queries  
> for the transfer, but this doesn't work since the entity joining  
> doesn't know what resources to ask for. Some kind of bulk transfer  
> method is required. SIP cannot be used for bulk transfer [RFC 4485,  
> Section 3.1]. Consequently, SIP will not meet this requirement.
>
> protocol that worked well for SIP, and not try to solve the general  
> p2p problem. However, this is NOT the same thing as saying that we  
> should build a p2p protocol that can ONLY be used for SIP! That is  
> the consequence of using dSIP - this will only ever be useful for  
> this application. I would rather define a p2p protocol that is  
> targeted at our requirements, and then future groups or  
> applications can consider extensions to meet their requirements if  
> a need arises.
>
> 3. Bandwidth
>
> requiring centralized resources. However, this comes with two  
> penalties. First, the latency for processing a lookup is increased  
> (grows logarithmically with the size of the network) and the  
> overall bandwidth required in the system increases.
>
> If you take a normal SIP client that is a participant in a 10M node  
> SIP network, and measure the traffic on its access link towards the  
> network, the traffic (considering just signaling) is not a function  
> of the network size and is relatively low. With a p2p network, the  
> node must process p2p network queries unrelated to its own calls,  
> which I believe scales with logN/N. Indeed, a frequent 'complaint'  
> about p2p networks is that it 'hogs the network'.
>
> Consequently, I think there is a real need to minimize the expense  
> of this connectivity, in terms of bandwidth. Very little of SIP is  
> actually needed in the peer protocol. You will be paying for lots  
> of bytes to transfer data you don't need. I would much rather  
> design a tiny little binary protocol that is highly bandwidth  
> optimized, to address the real issue and to address perception that  
> this protocol is expensive.
>
> A text protocol would be a poort choice here, a text protocol with  
> tons of extra fields you don't need is an even worse choice.
>
> 4. CPU
>
> Similar to the bandwidth issue, p2p protocols require CPU  
> processing that scales as logN/N. Again the perception is that p2p  
> networks keep my machine busy. I would therefore strive for a  
> trivial protocol where you can demonstrate the ability to support  
> tremendous amount of processing with little cost. SIP is a poor  
> choice here, since it is fairly complex in parsing and overall  
> processing. For general signaling, that tradeoff is a good one  
> because the need for generality in signaling. However, that  
> generality is not needed for a p2p mesh protocol and consequently  
> I think this will be hard for people to implement. The reason is  
> that most folks with an existing SIP stack will need to heavily  
> muck with that stack to insert these extensions. It would be much  
> nicer to separate the SIP pieces from the DHT maintenance. So, I  
> could go an implement a separate p2p protocol in a separate library  
> (or indeed use something that exists today to play around with it),  
> and simply 'plug in' the DHT computation, which ultimately converts  
> an AOR to an IP address, as an alternative to RFC 3263. Indeed,  
> many implementations already support pluggable mappings, so you'd  
> just need to drop this p2p library in a wrapper and voila - you  
> have p2psip.
>
>
>
>
> There is this belief that the converse is true; that you need to  
> use SIP to reuse STUN, TURN and ICE. This is false.
>
> STUN and TURN are not tied to ANY PROTOCOL. You can use both of  
> those equally well, without any changes to STUN or TURN, for a  
> brand new binary protocol as equally well as you could with SIP.
>
> ICE cannot be used with just any protocol, but it is not limited to  
> SIP. It is useful in any OFFER/ANSWER protocol. This does not  
> require SIP. You could instead define a new p2p binary protocol  
> that uses the O/A model for connections, and specify an alternate  
> syntactic encoding for the SDP, whether it is a binary compression  
> (not recommended), or simply a binary representation of only those  
> fields that are relevant. This would allow you to completely reuse  
> ICE without dealing with any of the overhead that the rest of SDP  
> brings with it.
>
> I'm not objecting to the basic flow of draft-matthews-p2psip-dsip- 
> nat-traversal-00.txt, which is actually very clever I think;  
> rather, I'm saying you can accomplish this same approach using ICE,  
> STUN and TURN, but do it with a custom protocol tuned to p2psip.
>
>
> Thanks,
> Jonathan R.
> --

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 20 Mar 2007 18:47:01 +0100

While CPU cost is obviously important, I think it's a tought tradeoff
with the traditional reasons for preferring ascii-based protocols.
Also, despite assertions otherwise, many (not all) of the headers in
SIP messages are used in dSIP maintenance operations.  The question of
exactly how many, whether they are all needed, and whether an ASCII
protocol can be sufficiently efficient, are all important questions.
But I would not be quick to give up the advantages of an ascii-based
protocol unless it could be proven that it will be too expensive and a
binary protocol is the only option.

Bruce

---

From: "Marcia " <[email-masked]>
Date: Tue, 20 Mar 2007 15:56:51 -0400

One advantage to using SIP over a custom protocol is not having to implement
multiple stacks on a peer.  A p2psip peer is going to have SIP stack on it
already.  A custom protocol would require a custom stack to handle those
protocol messages. If a goal is to keep the CPU processing low and a p2psip
peer is going to have a SIP stack on it already, seems like using SIP as a
peer protocol would be a win over implementing an additional stack.

--Marcia

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2007 18:00:46 -0400

There will also be DNS. IP. TCP. SMTP. HTTP. Doesn't mean you should use 
one of those. RFC 4485 talks about the 'but I laready have this protocol 
on my endpoint' argument.

-Jonathan R.

Marcia wrote:

> One advantage to using SIP over a custom protocol is not having to 
> implement multiple stacks on a peer.  A p2psip peer is going to have SIP 
> stack on it already.  A custom protocol would require a custom stack to 
> handle those protocol messages. If a goal is to keep the CPU processing 
> low and a p2psip peer is going to have a SIP stack on it already, seems 
> like using SIP as a peer protocol would be a win over implementing an 
> additional stack.
> 
> --Marcia
> 
> On 3/20/07, *Cullen Jennings* < [email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>      > [email-masked]
>     <mailto:[email-masked]>                              FAX:   (973)
>     952-5050
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: EKR <[email-masked]>
Date: Tue, 20 Mar 2007 23:39:24 -0700

> peer protocol would be a win over implementing an additional stack.

1. When you have two basically dissimilar protocols, it's generally
   more effort to implement them in a combined stack than to
   implement them in the same stack. Add to this the likelihood
   that during later protocol design phases we'll need to patch
   around constraints introduced by SIP, and it's pretty hard
   to see what the win is.

2. I don't get the processing argument. It's not like the new P2P
   stack is going to be parsing the same messages *simultaneously* with
   the SIP stack. How does having a single impl. save CPU.

-Ekr

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 21 Mar 2007 05:29:17 -0700

I completely agree with Jonathan. Please look at these arguments also as
pointers what the peer protocol should look like.

There are a number of problems in using SIP for DHT maintenance (as a
peer protocol). The biggest is that you can't keep the semantics of
existing SIP messages/headers and include all the potential DHT
messages/headers. It is obviously possible to extend SIP to add those
fields, but then what advantage do we gain from doing this if it doesn't
work well with existing SIP?

For DHT maintenance what we need is a RPC/RMI protocol. We can't predict
what new fields or new headers will be needed in future DHT algorithms.
If we carry DHT maintenance information in SIP, we might end up having
to continuously update the headers/fields. Alternative is to use the DHT
maintenance in the message body. But that doesn't give any advantage of
using SIP instead of using any other custom protocol, since we are not
using the semantics of SIP.

DHT maintenance typically involves various intricate details of the
algorithm. Many algorithms use bunch of binary data (SHA1) which needs
to be converted to SIP URI or SIP header or some textual representation
(e.g., using base64). This is neither efficient nor elegant in my
opinion. If we do want a text-based protocol, XML may be used instead
for RPC.

SIP has many implicit dependencies on things which are absolutely not
needed for DHT maintenance.
For example,
(1) DHT maintenance/refresh timers will be different than existing
recommended SIP timers.
(2) Loop detection algorithm in DHT may be different or may not even be
needed because some algorithm may actually require a loop (e.g., to
check liveness, you do a ping to yourself over the DHT).
(3) DHT message reliability and retransmission requirements may be
different.
(4) SIP requires DNS lookup, whereas DHT maintenance may/must not.
(5) SIP's security is targetted towards client-server systems, e.g., TLS
with server certificates, or shared secret with the server. DHT may not
want to rely on certificates from Verisign or elsewhere. Shared secret
doesn't work with unknown peers.
(6) A DHT peer may not want to implement both TCP and UDP transport
unlike SIP proxies, because it may not want to maintain 100s of TCP
connections to neighbors.
(7) A DHT may require that the response doesn't follow the same path as
the request, but be sent directly to the initiator. Using SIP means we
disallow this or have a separate request from the last node to the
initiator (inefficient).
(8) Recommended MaxForwards of 70, may not work well, e.g., if Chord
routing table gets corrupted due to network partition and the request
ends up going through subsequent nodes in the Chord ring.
Thus, existing SIP UA and proxy behavior needs to change a lot if it is
to be used in a DHT node for dSIP.

The points I am trying to make are: 
(a) if you want to use SIP for DHT maintenance without changing the
semantics, you will probably be able to implement one or two specific
DHTs, but not all the available/existing DHT algorithms. So, it puts
unnecessary constraints on what a DHT must/must not implement, thus
restricting the DHT innovation.
(b) If you want to modify SIP to accommodate general purpose DHT
maintenance, you will have to tweak SIP in a way that you basically
create an entirely new protocol. The questions is: can this tweaked SIP
be used where old SIP could be used? Answer is no.

Now, if we have to tweak SIP to accommodate DHT maintenance and in the
process also inherit all the complexity/unnecessary features of SIP, why
not create a new more efficient protocol just for this purpose?

I suspect that creating a new protocol that doesn't require SIP probably
won't fall within the P2P-SIP WG agenda. 

I think we should:
(1) define the exact requirements of the DHT maintenance and lookup
protocol that can be used in P2P-SIP. Leave the actual protocol message
to the implementors. Once we have a couple of successful
implementations, this can be standardized as well.
(2) Provide a client interface (either a programming API, SIP, binary
protocol, XML-RPC, or something else) to access a P2P-SIP node for
lookup and updates.

Thanks, Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 5:02 PM
To: [email-masked]
Subject: [P2PSIP] dSIP and whether to use SIP as th epeer protocol

Inappropriateness of SIP
------------------------

use of SIP identifiers to *require* that, for a particular domain, the 
user part cannot be used. This is a warning that something is amiss
here.

4. Implied Proxy-Require

    In the event

1. Other p2p operations

3. Bandwidth

4. CPU

using ICE, STUN and TURN, but do it with a custom protocol tuned to
p2psip.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2007 14:09:54 -0400

Henry, I agree with all of this up till the very end, where you say:

> implementations, this can be standardized as well.

We have a charter that has us developing a standards track peer protocol 
for p2psip. Unless we do that, there won't be interoperability. 
Protocols are what we do here, and its what we've been chartered to do. 
I don't see why would should abandon this deliverable.

-Jonathan R.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 22 Mar 2007 03:30:18 -0700

Jonathan,

> Protocols are what we do here, and it's what we've been chartered to
do

This is an excellent point and I believe we need to amend the charter
anyhow. The main amendment would be:

1. "The P2P SIP WG main deliverable will be protocols that have been
proven by running code and interoperability testing".

2. "Protocol proposals that are not backed up by running code will not
be considered as deliverables".

After all, p2p traffic already dominates the Internet and the charter
has to be realistic enough so as to enable success in this work.

Thanks, Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 7:10 PM
To: Henry Sinnreich
Cc: [email-masked]
Subject: Re: [P2PSIP] dSIP and whether to use SIP as th epeer protocol

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Mar 2007 13:55:58 +0100

True enough there are all kinds of tradeoffs.

On Mar 20, 2007, at 8:56 PM, Marcia wrote:

> implement multiple stacks on a peer.  A p2psip peer is going to  
> have SIP stack on it already.  A custom protocol would require a  
> custom stack to handle those protocol messages. If a goal is to  
> keep the CPU processing low and a p2psip peer is going to have a  
> SIP stack on it already, seems like using SIP as a peer protocol  
> would be a win over implementing an additional stack.
>
> --Marcia
>
> On 3/20/07, Cullen Jennings < [email-masked]> wrote:

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 22 Mar 2007 15:35:25 +0100

I agree with the intent that we need running code for protocols we
adopt, but I don't think such a clarification is needed in the charter
-- that is already implicitly true and is a fundamental principal of
all work at the IETF, I thought.

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com