Subject: [P2PSIP] Comments on RELOAD-01 for P2PSIP

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 11 Jul 2007 13:48:31 -0700

The new version of "REsource LOcation And Discovery (RELOAD)"
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bryan-p2psip-rel
oad-01.txt is a welcome opportunity to clear up some issues regarding
RELOAD itself, but also of larger interest to the P2PSIP WG. This is the
reason for my posting these comments here to the list. This posting is
not meant in any way to diminish the value of the RELOAD I-D, but as a
suggestion for future versions.

Section 3.3 P2PSIP

"Unlike a conventional SIP architecture, P2PSIP systems require no
central servers."

This is not an accurate statement and maybe "essentially no servers"
would be more accurate. The term "essentially no servers" must be
explained by examples of servers such as:

* Enrollment server(s)
* Bootstrap servers
* STUN/TURN relay servers
* Resource servers such as SIP proxies, VM, etc.

The importance of the enrollment server cannot be overstated, as mention
by Cullen Jennings in
http://www1.ietf.org/mail-archive/web/p2psip/current/msg02728.html 
This would also apply to section 11.2. Protecting the ID Namespace.

It may be also useful to state that all applications reside in the
endpoints and this is a key differentiator with C-S SIP
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-sinnreich-sip-to
ols-01.txt 
BTW: A new version of this I-D will be published soon.

4.1. P2P Overlay Structure
"For example, a simple SHA-1 hash of the IP address and the port of the
peer could be used to generate the Peer-IDs".

NO, NO, NO: As has been discussed here on the list and in the P2PSIP
Requirements
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bryan-p2psip-req
uirements-00.txt the IP address MUST NOT be used to generate the peer ID
since mobile devices with significant churn would generate frequent
reorganizations of the overlay and this must be avoided so as to support
_mobility_ in P2P SIP.

4.5. Routing in RELOAD
It appears the routing procedures using SIP in RELOAD are duplicating
the routing in the underlying DHT. If this is not the case, an
explanation would be helpful.

SIP itself and SIP messages are clearly not suitable for DHT routing and
this is explained in emails to this list and also in 
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-baset-p2psip-p2p
p-00.txt on page 60 in B.1.: To SIP or not to SIP.

11.4. Protecting the Routing
Protecting the routing can be done effectively at the DHT level, such as
described in "Secure routing for structured peer-to-peer overlay
networks" by M. Castro et al.
http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf 
This should be mentioned.

Concept Paper or Implementation Report?

As a general comment, it is not clear to what extent this I-D is a
conceptual memo or a proven implementation as indicated in the
Introduction.

If RELOAD is a proven implementation, I would expect to be able to
download and inspect the code and see performance reports such as are
available for example for Bamboo at http://opendht.org/ 

IMHO inspecting the code and seeing the performance reports by
simulations and on the network is THE top requirement in deciding the
selection of a P2PSIP protocol.

Just reading an I-D will not enable us to make any judgment on the value
of the proposal for real life product development. This is actually true
for other interesting concepts and proposals as well, such as using HIP
for P2PSIP.

Even just for reading the RELOAD I-D, examples would be very helpful,
especially for the more innovative aspects mentioned in 
1.1. Evolution of RELOAD.

We must recommend the authors for the excellent work done in the new
version of the RELOAD I-D and suggest addressing these issues.

And using the P2P SIP Requirements I-D first :-)

Thanks,

Henry Sinnreich

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 11 Jul 2007 18:42:20 -0400

> * Resource servers such as SIP proxies, VM, etc.

Strictly speaking, none of those are required to be centralized for
P2PSIP, especially in the small group ad hoc type of use cases.  It's
certainly true that for the more public cases, especially with
security involved, enrollment servers are likely to be centralized.
Bootstrap servers is an interesting question, as whether they can be
"discovered" in a P2P way or must be registered in DNS depends a lot
on the specifics of the deployment.   I would argue that the
functionality of STUN/TURN relay servers and the resource servers
should be distributed among the peers.

> reorganizations of the overlay and this must be avoided so as to support

Sorry, that was intended to be an example, but you're right it should
probably be reworded in that section.  Section 6.1.1 is where the
draft talks about a few options for generating Peer-IDs.
(specifically it says MAY use hashed IP and port but SHOULD use
UUID-based PeerIDs.)  UUIDs are much better for your (and many other)
scenarios, but I think in a lot of cases you're still going to want
the PeerIDs to come out of certificates, as in reload-security.

> p-00.txt on page 60 in B.1.: To SIP or not to SIP.

Hmmm.  I'm not sure where the draft is unclear, but we will work to
clarify it and maybe we can talk in Chicago to make sure it's clearer.
 But to try again, RELOAD does not in any way base DHT routing on
anything involving SIP.  RELOAD offers the possibility of routing SIP
on top of the DHT through the TRANSPORT-TUNNEL method, but that is
intended primarily as a way of NAT traversal and the intention is that
if two P2PSIP UAs wish to establish a SIP dialog for more than a small
number of message exchanges, they will do so directly, possibly using
TRANSPORT-OPEN methods to do ICE to open a direct SIP dialog.

> 1.1. Evolution of RELOAD.

You're right, it definitely needs more examples.  Maybe we'll get the
time before Vancouver...

Bruce