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

From: "Christian Esteve" <[email-masked]>
Date: Tue, 20 Mar 2007 20:02:27 -0300

I have my doubts on how much of a standard SIP stack is reused in a dSIP
implementation. The tweaks and new semantics introduced by dSIP require the
definition of branches in the SIP stack to differntiate between standard SIP
and dSIP modes of operation.
IMHO, the resulting stack would end up in a computational heavier process
compared to an additional efficient DHT protocol stack optimized in terms of
timings, message size, overhead, etc.
This is something programmers can estimate more precisely than I do.

And something I would like to ask to "classic p2p" experts: How many
successful dht protocols are text-based and how many binary? What are the
bottlenecks of existing p2p deployments?

Fully agree with Kundan's work proposal; let's concentrate our efforts on
defining the requirements of the DHT maintenance and lookup procedures for
P2PSIP purposes. How different are the requirements of maintaining a DHT for
a file sharing service comparing to the goal of enabling a SIP service?

Best wishes,
Christian

> ------------------------------
> 
> Message: 2
> Date: Tue, 20 Mar 2007 15:56:51 -0400
> From: "Marcia " <[email-masked]>
> Subject: Re: [P2PSIP] dSIP and whether to use SIP as th epeer protocol
> To: "Cullen Jennings" <[email-masked]>
> Cc: P2PSIP WG <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 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]> wrote:
> >
> >
> > 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:
> >
> > > 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
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/p2psip/attachments/20070320/b1413888/attach
> ment.html
> 
> ------------------------------
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
> 
> 
> End of P2PSIP Digest, Vol 3, Issue 42
> *************************************

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

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 21 Mar 2007 00:22:37 +0100

For what it's worth, the implementation we have of dSIP today uses a
tweaked standard SIP stack. Most allow you to add new headers and
fields. I think it safe to say 90-95% of the stack code (maybe more)
is completely untouched. Most code that is unique is in the
application.

David

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

---

From: Karst Bjorgson <[email-masked]>
Date: Wed, 21 Mar 2007 01:55:29 -0700 (PDT)

> bottlenecks of existing p2p deployments?

Typical DHT protocols are binary encoded. But I think
that equating P2P with DHT is a mistake. There are at
least two other possible structures.

The Gnutella protocol and its variants perform search
by asking a question to a set of "neighbors", and then
possibly have them relay the question another step or
two. An equivalent with SIP may be to maintain
associations with a list of "buddies", and relay
invites through these buddies. This is less structured
than a DHT, but has at least one interesting
advantage: a much better handling of privacy. With a
DHT, a nodes address is published to the entire
network. In a Gnutella like system, it would only
published to its buddies, which limits opportunities
for spammers and stalkers.

The Freenet protocol also resolves queries without a
formal DHT, by simply relaying queries to the node
that looks closer in the name space. Microsoft's PNRP
implements a similar strategy. Relying on name space
proximity removes the need for a formal exchange of
routing tables or fingers. The system simply learns as
a side effect of the traffic. It also allows for
better locality, if the name space is structured.

Bottom line, DHT may or may not be right approach, and
should be better left optional.

-- Karst

____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097