Subject: [P2PSIP] Re: dSIP and whether to use SIP as the peer protocol

From: "Kundan Singh" <[email-masked]>
Date: Tue, 20 Mar 2007 12:08:27 -0700

I completely agree with Jonathan.

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.

Regards.

> On Mar 20, 2007, at 5:02 PM, Jonathan Rosenberg wrote:
> 
> > 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: "Eunsoo Shim" <[email-masked]>
Date: Tue, 20 Mar 2007 22:04:55 -0400

I agree with Jonathan and most of what Kundan wrote.

Especially I like the following paragraph from Jonathan's email:

"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."

P2PSIP does not necessarily mean tweaking SIP or defining SIP extensions for
P2P.
Actually as Jonathan pointed out, a completely separate protocol for P2P and
using it for SIP is a much better approach.

So I don't agree to the following sentence in Kundan's email:
"I suspect that creating a new protocol that doesn't require SIP probably
won't fall within the P2P-SIP WG agenda."

In contrary to the above sentence, my understanding is that creating a new
protocol for P2P and thus P2PSIP is well within the P2PSIP WG agenda. It is
defining Peer Protocol and Client Protocol as written in the charter!

Thanks.

Eunsoo

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 21 Mar 2007 07:35:05 +0100

Ignoring the specifics of this situation...

Could we agree that if out charter requires that we do something that doesn't turn out to be a great idea, we fix the charter instead of walking off the cliff?

Spencer
  P2PSIP does not necessarily mean tweaking SIP or defining SIP extensions for P2P. 
  Actually as Jonathan pointed out, a completely separate protocol for P2P and using it for SIP is a much better approach.

  In contrary to the above sentence, my understanding is that creating a new protocol for P2P and thus P2PSIP is well within the P2PSIP WG agenda. It is defining Peer Protocol and Client Protocol as written in the charter! 
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 21 Mar 2007 02:50:14 -0400

Sure.

But, to repeat myself, the current charter is fine as it is.
The charter does not require any protocol choice for the Peer Protocol or
the Client Protocol.
The choice is completely open for the WG.
Thanks.

Eunsoo

On 3/21/07, Spencer Dawkins <[email-masked]> wrote:
> Could we agree that if out charter requires that we do something that
> doesn't turn out to be a great idea, we fix the charter instead of walking
> off the cliff?
>
> Spencer
>
> Actually as Jonathan pointed out, a completely separate protocol for P2P
> and using it for SIP is a much better approach.
>