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

From: Philip Matthews <[email-masked]>
Date: Fri, 2 Mar 2007 20:29:20 -0500

Jonathan:

I am currently putting the final touches on the -04 revision of the  
Concepts document.
As part of this effort, I have just reviewed your comment.
See my replies below.

I should add that there was a major rewrite of section 3 and many of  
the sentences
you mention below have been replaced. However, I made sure that your  
general
concerns were covered.

- Philip

On 3-Nov-06, at 17:38 , Jonathan Rosenberg wrote:

> 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
>>
name within the overlay (example:
>
> Don't use "distinguished name" here. It's a technical term from
> PKIX and it doesn't mean this. "unique name"?

The text now talks about a "unique name".

>
> S 4.5.
>
>    When forwarding requests, are the bodies of the requests visible to
>    peers?  If so, this creates substantial security problems that the
>    deployers of conventional SIP have been willing to mostly ignore.
>    Can we make peers cryptotransparent (like HTTP proxies) when  
> security
>    is requested?
>
> I don't think I understand what "cryptotransparent" means, and since
> HTTP proxies operate in a bunch of different modes, some quite  
> transparent
> and some quite invasive. Maybe just rename this to "security of  
> requests"
> and remove the last sentence?

I have rewritten this section to remove "cryptotransparency and  
remove the last sentence.

- Philip

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

---

From: Philip Matthews <[email-masked]>
Date: Fri, 2 Mar 2007 20:29:20 -0500

Jonathan:

- Philip

On 3-Nov-06, at 17:38 , Jonathan Rosenberg wrote:

>> 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 document now explicitly introduces the concept of a "Service" and  
talks
about locating peers that offer a particular Service. STUN servers  
are explicitly
mentioned as a possible service.

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

My personal plan is to update this section if and when the document
gets accepted by the working group as its "architectural overview"  
document.
Until then, I didn't think it was worth fixing this.

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

This sentence has been removed and there is now a whole section
that talks about approaches to the NAT Traversal problem.

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

The text now reads:

    P2PSIP Resource-ID:  A non-human-friendly value that uniquely
       identifies a resource and which is used as a key for storing and
       retrieving data about the resource.  One way to generate a
       Resource-ID is by applying a mapping function to some other  
unique
       name (e.g., User Name or Service Name) for the resource.  The
       Resource-ID is used by the distributed database algorithm to
       determine the peer or peers that are responsible for storing the
       data for the overlay.

>
>
>>  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 =>>
>>
>> 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 document now explicitly introduces the concept of a "Service" and  
talks
about locating peers that offer a particular Service. STUN servers  
are explicitly
mentioned as a possible service.

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

My personal plan is to update this section if and when the document
gets accepted by the working group as its "architectural overview"  
document.
Until then, I didn't think it was worth fixing this.

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

This sentence has been removed and there is now a whole section
that talks about approaches to the NAT Traversal problem.

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

The text now reads:

    P2PSIP Resource-ID:  A non-human-friendly value that uniquely
       identifies a resource and which is used as a key for storing and
       retrieving data about the resource.  One way to generate a
       Resource-ID is by applying a mapping function to some other  
unique
       name (e.g., User Name or Service Name) for the resource.  The
       Resource-ID is used by the distributed database algorithm to
       determine the peer or peers that are responsible for storing the
       data for the overlay.

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

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

Fixed.

>
>>   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?

The text now says that finding a gateway might be viewed as finding a
peer that offers a gateway service.

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

The discussion on clients has been completely rewritten.

>
>> 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 document  now says that a P2PSIP Overlay provides a "transport  
service"
for getting SIP messages from one peer/client to another in order to  
solve
the NAT traversal issue.

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

The document breaks this problem into two parts: finding a peer or peers
willing to be gateways, and selecting one of them for a call.
It says that the "finding a service" can solve the first problem,
and suggests that the second problem might be out-of-scope for now.

>
> 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)?

There is a bit of text on this, but not a lot.
This is something for a future revision.

>
>>  o  Enrolling 20
>> fairly
>>       stable and well-known host.
>
> I think you mean Bootstrap Server in this last sentence.
Fixed.

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

Fixed.

>
>>   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?

The text now says that finding a gateway might be viewed as finding a
peer that offers a gateway service.

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

The discussion on clients has been completely rewritten.

>
>> 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 document  now says that a P2PSIP Overlay provides a "transport  
service"
for getting SIP messages from one peer/client to another in order to  
solve
the NAT traversal issue.

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

The document breaks this problem into two parts: finding a peer or peers
willing to be gateways, and selecting one of them for a call.
It says that the "finding a service" can solve the first problem,
and suggests that the second problem might be out-of-scope for now.

>
> 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)?

There is a bit of text on this, but not a lot.
This is something for a future revision.

>
>>  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?

See my comments on  the transport service above.
This particular list of operations has vanished as part of a big  
rewrite.\

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

Fixed as part of the rewrite.

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

This particular example is done, but the introduction of the  
transport service
fixes this problem.

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

All gone as part of the rewrite.

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

These sentences are now gone.

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

See above.

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

Nor do we, yet.

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

Fixed.

>
>>  This model presumes that all addressable elements, aka "users", are
>>    unique.  Are their other classes of resources that needa 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?

See my comments on  the transport service above.
This particular list of operations has vanished as part of a big  
rewrite.\

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

Fixed as part of the rewrite.

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

This particular example is done, but the introduction of the  
transport service
fixes this problem.

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

All gone as part of the rewrite.

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

These sentences are now gone.

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

See above.

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

Nor do we, yet.

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

Fixed.

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

Services are now identified with a "Service Name" which uniquely  
identifies
the service, but not where it is located.

- Philip

 some  
>> sort of
>>    class-addressable identifier that does not refer to a unique user?
>
> This is exactly the problem with gateways and turn servers.

Services are now identified with a "Service Name" which uniquely  
identifies
the service, but not where it is located.

- Philip