Subject: [p2p-sip] comments on draft-willis-p2psip-concepts-03

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Fri, 03 Nov 2006 17:38:31 -0500

Overall, this document looks pretty decent to me. My comments below come
mostly from an 'outsider' to p2psip, in that I have not been actively
following the list.

> This document defines concepts and terminology for use of the Session
>  Initiation Protocol in a peer-to-peer environment where the
> 
> 
> 
> Bryan, et al.            Expires April 25, 2007                 [Page
> 1]  Internet-Draft       P2PSIP Concepts and Terminology
> October 2006
> 
> 
> traditional proxy-registrar function is replaced by a distributed 
> mechanism that might be implemented using a distributed hash table or
>  other distributed data mechanism with similar external properties.

THe abstract makes it pretty clear that p2psip is meant to just handle a
distributed registrar, rather than a mechanism for finding other SIP
resources (most notably, media relays/TURN servers). Generally I found
the document unclear about whether discovery of those kinds of resources
is in scope.

> The authors believe that this goal is roughly consistent with that of
> a Protocol Model as defined in [13].

This is perhaps a nit; but I've viewed rfc4101 as asking for short
overview sections as part of the spec. This doc is not short and since
there is not even a protocol, not really an overview.

> P2PSIP:  A suite of communications protocols related to the Session 
> Initiation Protocol (SIP) [3] that extends SIP by using peer-to- peer
> techniques for resolving the targets of SIP requests.  The

OK - so not discovering relays then?

> A notable property of P2PSIP Peers is that they can be fully
> functional peers while residing behind NATs.  Contrast this with some
> other
> 
> 
> 
> Bryan, et al.            Expires April 25, 2007                 [Page
> 6]  Internet-Draft       P2PSIP Concepts and Terminology
> October 2006
> 
> 
> P2P systems which make a distinction between "peer" and "super- peer"
> (or "node" and "super-node") where the latter must have a public IP
> address.

This is a bold claim. Seems like you are dismissing the notion of
supernodes as part of the design. Is that purposeful? Getting nat
traversal to work without any kind of bootstramp element is very hard.

> P2PSIP Resource-ID:  A non-human friendly value that uniquely 
> determines which P2PSIP Peer is responsible for storing information
> about this resource (user).  In a DHT approach, this is a numeric
> value in the hash space resulting from hashing the P2PSIP Resource
> Name.  Since Resource-ID is in the same space as the P2PSIP Peer-ID,
> it allows for a mapping between the values, used to map a P2PSIP
> Resource to the P2PSIP Peer that stores it.

Its association with a node in the overlay is a consequence of the DHT
algorithm, not an inherent property of the identifier itself. The
identifier identifies the resource, not the node on which it is stored.

>  P2PSIP Bootstrap Server:  A network node used by other nodes which
>       are attempting to contact a P2PSIP Bootstrap Peer.  It may return
>       the address of a P2PSIP Bootstrap Peer, or act as a proxy to relay
>       messages to and from the Bootstrap Peer, or act as a Bootstrap
>       Peer itself.  The P2PSIP Bootstrap Peer itself should be a fairly
>       stable and well-known host.  

I think you mean Bootstrap Server in this last sentence.

>  P2PSIP Peer Insertion:  The act of inserting a P2PSIP Peer into the
>       current routing structure (presumably a distributed database or
>       hash table) of a P2PSIP Overlay.  For example, the routing
>       structure map the peer's IP address or DNS name to the peer's
>       P2PSIP Peer-ID.

This last sentence doesn't parse.

>   2.  Media relay: a P2PSIP peer or client capable of relaying media
>        sessions.  For example, an RTP relay as described in [14]

This is the bit that made me think you could use the mesh to find TURN 
servers. If not, this needs to be clarified.

> Gateway: a P2PSIP peer or client that converts from P2PSIP to
>        some other protocol, such as PSTN (Public Switched Telephone
>        Network).

How would this work? Would you use the p2p mesh to find gateway resources?

> In a solution where the P2PSIP Client
>    Protocol is SIP, such as is proposed in [7], there may no difference
>    between UA client "C" and standard SIP UA "A".

This contradicts your terminology, where you say that a P2PSIP UA is 
distinguished in that it knows about p2p operations. It seems to me that 
even if the client protocol is sip, you'd still need to do something 
different with regard to bootstrapping...

> Both the "Proxy Peers" and "Redirect Peers" can serve as adapters
>    between ordinary SIP devices and the the P2PSIP Overlay.  Each
>    accepts standard SIP requests and resolves the next-hop by using the
>    P2PSIP overlay Peer Protocol to interact with the routing knowledge
>    of the P2PSIP Overlay, then processes the SIP requests as appropriate
>    (proxying or redirecting towards the next-hop).  Note that proxy
>    operation is bidirectional - the proxy may be forwarding a request
>    from an ordinary SIP device to the P2PSIP overlay, or from the P2PSIP
>    overlay to an ordinary SIP device.

What about requests between p2psip peers? What if two peers can't 
directly reach each other due to nat. Would a proxy peer serve the role 
of connecting them together?

> The Gateway Peer provides a similar sort of adaptation to and from
>    the public switched telephone network (PSTN).  However, there is a
>    subtle distinction.  The gateway function itself can be viewed as a
>    "user" or within the P2PSIP overlay, and is addressed using a P2PSIP
>    Overlay User Identifier.  

The latter is never defined by your terminology. Do you mean P2PSIP 
Resource-ID? I have a hard time understanding how this is going to work. 
PSTN gateways don't have a (useful) unique identifier. Rather, when I 
want to mkae a call to a number, any gateway might potentially work. 
What resource name would I use when trying to find the gateway? The 
problem is that gateway selection is not easily modeled as a hash table 
lookup operation, so I have a hard time understanding how it fits in.

I also think it would help a lot to spend some time on how SIP 
interworks with p2psip. Can a regular sip client call a p2p-sip client? 
Would this require that a overlay ID map 1-1 with a domain name (I think 
so)?

>  o  Enrolling a Peer in the Overlay
> 
>    o  Inserting a P2PSIP Peer into the Overlay
> 
>    o  Enrolling a Resource or User in the Overlay
> 
>    o  Inserting a Resource or User into the Overlay
> 
>    o  Retrieve information about a Resource or User from the Overlay

A notable omission here is "Reach a resource or user from the overlay". 
Retrieving information (namely its IP) would seem to imply that it is 
always directly reachable and we know that is not going to be true. What 
operation is used in that case? Or if it is a retrieval, would you 
retrieve a p2psip proxy to which that user has a connection/flow?

> Finally, it should be re-iterated that the Client Protocol is a
>    strict subset of the Peer Protocol (at least logically, the two may
>    differ syntactically).  This has two consequences:

Actually its been reiterated like three times already....

> 3.4.3.  Conventional SIP Device using a Proxy Peer

This flow here makes it seem like a proxy peer is only used by normal 
sip UA and not peers. Per above I don't see how this is working on the 
presence of nat.

> 3.5.2.  More on The Difference Between a Peer, Client, and User Agent
> 
>    P2PSIP Peers directly interact with and contain the routing and
>    storage fabric of the overlay.  P2PSIP Clients simply use the routing
>    and storage facilities provided by the peers to get and put
>    information.  The peers speak the P2PSIP Peer Protocol, which can
>    express all the necessary routing and storage operations required for
>    the overlay.  Clients speak the P2PSIP Client protocol, which is
>    presumably a subset of the peer protocol, and is limited to storage
>    insertion (put) and storage retrieval (get).  Some designs do not
>    require a separate client protocol.

very repetitive. You've said this several times now.

>  Presumably, the P2PSIP UA connects to a
>    peer or client and uses the user's credentials to authenticate a
>    route-set (Contact: plus Path:) to itself, and the peer or client
>    stores the route-set into the overlay, using a key derived from the
>    user's identity.

Authenticate a route set or insert a route set? This is confusing. 
Insertion of a route-set would seem to imply that you ARE using peers as 
proxies when going from one peer to another. This contradicts text and 
figures above.

> In the typical case, the peer or client coming up is also a P2PSIP
>    User Agent with one or more associated P2PSIP Resource (User)
>    Identifiers.  The next step then is to insert a P2PSIP Resource
>    Record (a Contact:) into the P2PSIP Overlay.

Now, here its a Contact and not a Path/Contact.

> 4.3.  How Do We Find Gateways?
> 
>    This needs to be not only netpath efficient, but also embodies
>    elements of the TRIP and SPEERMINT problems.

Right - this is my point. I don't see how this works.

> We presume that the question of how to send media between two peers
>    or clients is already solved by the STUN/TURN/ICE suite of protocols,
>    assuming that the necessary STUN servers and media relays can be
>    located.

:)

> 4.13.  Admissions Control
> 
>    What do we need to say about admissions control with respect to the
>    enrollment of peers and users?  Do we need to discuss per-call
>    admissions control in a P2P environment?

terminology wise, I'd suggest not to use 'admission control' since it 
has well-defined meaning and a LOT of baggage already.

>  This model presumes that all addressable elements, aka "users", are
>    unique.  Are their other classes of resources that need some sort of
>    class-addressable identifier that does not refer to a unique user?

This is exactly the problem with gateways and turn servers.

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

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Sun, 5 Nov 2006 10:52:54 -0600

> the document unclear about whether discovery of those kinds of  

That's a true statement. It is unclear about searching for  
differentiated resources. We need to make a decision -- either all  
peers support all resource functions, or we need to have a search  
mechanism.

> OK - so not discovering relays then?

Open question.

> traversal to work without any kind of bootstramp element is very hard.

No, we're just saying that not ALL supernodes require public IP  
addresses. This position was established after months of debate.

> identifier identifies the resource, not the node on which it is  

Yeah, this def once said something like that, I think, and was  
subsumed by a DHT-centric definition.

> I think you mean Bootstrap Server in this last sentence.

I agree.
> This last sentence doesn't parse.

The noun "map" should be replaced with the verb "maps".

> servers. If not, this needs to be clarified.

Indeed.

> How would this work? Would you use the p2p mesh to find gateway  

Indirectly. You'd need some telephony-routing mechanism to decide  
which gateway to use, and then use P2PSIP to find that gateway.

Of course, if we end up changing the model to provide differentiated  
resource searching, I suppose one could do telephony routing that way  
as well.

> different with regard to bootstrapping...

Yeah, we had extended discussion on the above, and it's poorly  
worded. One might build a P2PSIP architecture that doesn't have a  
client protocol or clients as defined in this document. Just peers  
and plain old SIP UAs.

> of connecting them together?

Not normally. Peers route P2PSIP Peer Protocol request on behalf of  
other peers. Proxy Peers route SIP requests. They're different.

> lookup operation, so I have a hard time understanding how it fits in.

One model would be to use TRIP to find a URI for a gateway servicing  
that phone number, then use P2PSIP to contact the gateway.

> interworks with p2psip. Can a regular sip client call a p2p-sip  

Yes.

> Would this require that a overlay ID map 1-1 with a domain name (I  

While not required, such a mapping is one of our assumptions.

> retrieve a p2psip proxy to which that user has a connection/flow?

The information that is retrieved could be a route-vector instead of  
just an IP address.

> Actually its been reiterated like three times already....

Yeah, we're trying the "say it again in different words, louder,  
'cause they just ain't getting it" trick.

> sip UA and not peers. Per above I don't see how this is working on the

One uses "outbound" between the proxy-peer and the SIP-UA.

> very repetitive. You've said this several times now.

yeah, we added repetition every time somebody seemed to think it was  
needed for comprehension.

> Now, here its a Contact and not a Path/Contact.

Should be a "route vector" using my preferred vocabulary.

> Right - this is my point. I don't see how this works.

Not our problem, I hope.

> has well-defined meaning and a LOT of baggage already.

Actually, the "admissions control in a P2P environment" part is  
intended to be consistent with that well-defined meaning. And we're  
hoping the naswer (which you seem to agree with) is "no".

> This is exactly the problem with gateways and turn servers.

And that should be "there", not "their". Probably my bad.

--
Dean

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Sun, 5 Nov 2006 18:44:28 -0500

Jonathan:

Just adding a bit to Dean's reply to your comments.

Most of my comments are in-line, but first a general comment.
Yes, the authors are aware that the current  version (-03) has
a number of internal inconsistencies and is very repetitive
in some areas.  A lot of this is because three of the four authors
have taken a hand at editing the document, where the last two iterations
were in rapid succession under a tight deadline. When I submitted
-03, I KNEW there were still problems, but I had run out of time.

We hope that the next version of the document will clean
some of this up.

The rest of my comments are inline.

> peers support all resource functions, or we need to have a search

I second Dean's reply. The draft IS unclear in this area, and we need
to make a decision on differentiated resources.

My own opinion is that only some peers and clients will be willing and
able to act as proxies or STUN servers or media relays or gateways or  
whatever,
so we need a way to find such peers.

> addresses. This position was established after months of debate.

Some people say that:
	P2PSIP peer 	= super-peer in some other P2P networks
	P2PSIP client	= ordinary peer in some other P2P networks
(Personally, I am leery of this, but this might help you.)
If you take this identification, then we are saying that superpeers
can have private IP addresses.

>> I think you mean Bootstrap Server in this last sentence.

Yes. That is a typo on my part.

> The information that is retrieved could be a route-vector instead of

The current version of the document mostly ignores the fact that
some peers may not be directly reachable because they are behind
NATs. There is a comment to this effect in  the examples section,
but the problem is pervasive throughout the document.
It is something we need to fix in the next version.

>>>    assuming that the necessary STUN servers and media relays can be

Indeed. Thanks for your hard work on STUN/TURN/ICE.

- Philip

---

From: enrico.marocco at telecomitalia.it (Marocco Enrico)
Date: Mon, 6 Nov 2006 19:33:54 +0100

> Would this require that a overlay ID map 1-1 with a domain name (I think 

David and I have started thinking about it and and have proposed a
possible approach (draft-marocco-p2psip-interwork-00) which also deals
with discovery of relay resources.  However such a work is probably
worth doing after we have a WG formed, so no much attention has been
actually spent on it.

--
Ciao,
Enrico

Sorry..  the notice below is not my fault :-(
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------