Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 3 Oct 2006 14:30:30 -0500

More cleanup on pictures...

I'm explicitly showing a proxy that provides overlay clients access to the 
overlay (Proxy Peer Q). This addresses the discussion earlier in this 
thread, since UA Client C will be sending GET/PUT requests via unicast to a 
specific overlay peer.

I agree with David that the Proxy Peer may provide more than just 
forwarding/redirection - specifically, David mentioned Registrar 
functionality, and if I understood correctly, Eunsoo agreed.

I'll start working on text that covers these three pictures, starting with 
what's in Section 3.2 (which would cover the first figure). I'll keep it 
short, to avoid conflicts with Section 3.3.

We're just under three weeks away from the final ID cutoff date for IETF 67. 
I'm assuming that we'll submit an updated version of this (excellent) draft 
in time for discussion at the second BOF meeting - if so, when do the 
editors expect to submit 02?

I should have asked this already - is this draft in XML? Just so I know what 
to provide to the editors...

Spencer
                                             --->PSTN
                               +---------+  /
    +------+        |N|        | Gateway |-/
    |      |########|A|########|   Peer  |##############
    |  UA  |        |T|        |    G    |             #   Client Protocol
    | Peer |                   +---------+             #    GET/PUT
    |  C   |                                           #      |
    +------+                                           #      |   \__/
       #                                           +-------+  v   /  \
     |NAT|                                         |       |=====/ UA \
       #                      P2PSIP Overlay       | Proxy |    /Client\
       #                                           | Peer  |    |___C__|
       #                        Route Data         |   Q   |
    +------+      +------+                         +-------+
    |      | |N|  |      |                             #
    |  UA  |#|A|##|  UA  |                             #
    | Peer | |T|  | Peer |                             #
    |  D   |      |  E   |                             #
    +------+      +------+                             #
        Peer Protocol #   +-------+        +-------+   #
                      #   |       |        |       |   #
                      ####| Proxy |########| Redir |####
                          | Peer  |        | Peer  |
                          |   P   |        |   R   |
                          +-------+        +-------+

                 \__/                                   \__/
                  /\                                     /\
                 /  \                                   /  \
                / UA \                                 / UA \
               /______\                               /______\
               SIP UA A                               SIP UA B

   Figure: P2PSIP Overlay Reference Model

In the following picture, I'm showing normal SIP signaling through from SIP
UA A to UA Peer E, through Proxy Peer C.
                                             --->PSTN
                               +---------+  /
    +------+        |N|        | Gateway |-/
    |      |########|A|########|   Peer  |##############
    |  UA  |        |T|        |    G    |             #   Client Protocol
    | Peer |                   +---------+             #    GET/PUT
    |  C   |                                           #      |
    +------+                                           #      |   \__/
       #                                           +-------+  v   /  \
     |NAT|                                         |       |=====/ UA \
       #                      P2PSIP Overlay       | Proxy |    /Client\
       #                                           | Peer  |    |___C__|
       #                        Route Data         |   Q   |
    +------+      +------+                         +-------+
    |      | |N|  |      |                             #
    |  UA  |#|A|##|  UA  |----- SIP                    #
    | Peer | |T|  | Peer |    |  INVITE/200 OK         #
    |  D   |      |  E   |    |                        #
    +------+      +------+    |                        #
        Peer Protocol #   +-------+        +-------+   #
                      #   |       |        |       |   #
                      ####| Proxy |########| Redir |####
                          | Peer  |        | Peer  |
                          |   P   |        |   R   |
                          +-------+        +-------+
                         /
                        /
                 \__/  / SIP                            \__/
                  /\  /   INVITE/200 OK                  /\
                 /  \/                                  /  \
                / UA \                                 / UA \
               /______\                               /______\
               SIP UA A                               SIP UA B

   Figure: Proxied SIP call from SIP UA to P2PSIP UA through Peer Proxy

In the following figure, I'm showing the SIP signaling for a call initiated
from outside the P2PSIP Overlay to a Client, with redirect from a Redirect
Peer.
                                             --->PSTN
                               +---------+  /
    +------+        |N|        | Gateway |-/
    |      |########|A|########|   Peer  |##############
    |  UA  |        |T|        |    G    |             #   Client Protocol
    | Peer |                   +---------+             #    GET/PUT
    |  C   |                                           #      |
    +------+                                           #      |   \__/
       #                                           +-------+  v   /  \
     |NAT|                                         |       |=====/ UA \
       #                      P2PSIP Overlay       | Proxy |    /Client\
       #                                           | Peer  |    |___C__|
       #                        Route Data         |   Q   |       ^
    +------+      +------+                         +-------+       |
    |      | |N|  |      |                             #           |
    |  UA  |#|A|##|  UA  |                             #           |
    | Peer | |T|  | Peer |                             #           |
    |  D   |      |  E   |                             #           |
    +------+      +------+                             #   SIP     |
        Peer Protocol #   +-------+        +-------+   #  INVITE/200 OK
                      #   |       |        |       |   #           |
                      ####| Proxy |########| Redir |####           |
                          | Peer  |        | Peer  |               |
                          |   P   |        |   R   |              /
                          +-------+        +-------+             /
                                                   \            /
                                     SIP            \          /
                 \__/               INVITE/302 Moved \  \__/  /
                  /\                                  \  /\  /
                 /  \                                  \/  \/
                / UA \                                 / UA \
               /______\                               /______\
               SIP UA A                               SIP UA B

   Figure: Redirect from P2PSIP Overlay

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 3 Oct 2006 17:17:51 -0500

This is my first shot at Section 3.2. Please let me know if I have
misunderstood, or misspoken.

I'm also wondering if the second and third figures would be clearer if I 
showed only one SIP UA in each figure, so it would be easier to spot the SIP 
UA that's involved in the dialog.

Thanks!

Spencer

3.2.  Reference Model

The following diagram depicts a reference or "boxes and arrows" model
showing several of the above peer and client types, along with two
conventional SIP user agents.

                                             --->PSTN
                               +---------+  /

                 \__/                                   \__/
                  /\                                     /\
                 /  \                                   /  \
                / UA \                                 / UA \
               /______\                               /______\
               SIP UA A                               SIP UA B

Here, the large perimeter depicted by "#" represents the P2PSIP Overlay and
its associated routing data.  Around the periphery of the P2PSIP Overlay
rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN
gateway, a user-agent, two proxies, and a redirector.

To the left we have two UA peers, which are included in the overlay even
though they are behind network address translators.

On the right side, we have a P2PSIP Overlay "UA client", which uses the
P2PSIP Overlay Client Protocol depicted by "=" to communicate with Peer
Proxy P, and indirectly interacting with the P2PSIP Overlay.

Below the P2PSIP Overlay, we have conventional SIP UAs "A" and "B", which
are not part of the P2PSIP Overlay, either directly as a peer or indirectly
as a client. Instead, they use SIP to interact with with the P2PSIP Overlay.

Note that the Proxy Peers and the UA Peers interact using the P2PSIP Overlay
Peer Protocol, which is also presumably used on the keepalive links between
the UA Peers and their neighbors.

(Spencer's note: I'm not happy about either "keepalive" OR "links" in this
sentence. I understand Dean's point that "keepalive" may derive from the
Outbound draft, but these aren't "links" in the normal sense of the word,
and if we're mandating operation of "keepalive" signaling, that has some
fairly serious implications for some of the use cases. Suggest "which is
also presumably used between the UA Peers and their neighbors".)

Both the "Proxy Peers" and "Redir Peer" serve as adapters between
ordinary SIP devices and the the P2PSIP Overlay.  Each accepts 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.

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.  This gateway functionality could also be
located in a P2PSIP Overlay Client, or even in a traditional SIP UA
that is reached via P2P (using a P2P proxy or redirector) or
conventional SIP mechanisms.

The following diagram shows a conventional SIP device, SIP UA A,
establishing a dialog with UA Peer E, by sending a SIP INVITE to Proxy Peer
P, which forwards the request towards its next-hop, which happens to be part
of the P2PSIP Overlay.

                                             --->PSTN
                               +---------+  /

   Figure: Proxied SIP dialog from SIP UA to P2PSIP UA through Peer Proxy

The following diagram shows a second SIP UA "B" establishing a dialog with a
P2PSIP Client UA "C", by sending a SIP INVITE to the Redirect Peer "R",
which redirects SIP UA "B" to P2PSIP Overlay Client "C", using the normal
SIP 302 mechanism. The conventional SIP UA "B" device can then establish the
dialog directly with UA Client "C", even though "B" has no awareness of the
P2PSIP Overlay, or of the P2PSIP Overlay Client Protocol.

                                             --->PSTN
                               +---------+  /

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 4 Oct 2006 16:38:13 -0500

On Sep 28, 2006, at 7:41 AM, Spencer Dawkins wrote:

> ... I'm still working on precision here ...
>
> I may have misunderstood this point in the original draft, but I  
> thought the
> Proxy Peer was a *SIP* Proxy Peer - roughly, providing what I called
> "Interaction with CS-SIP" in http://www.p2psip.org/P2PUseCases.php.
>
> But, looking back at draft-willis-p2psip-concepts-01 more closely,  
> I find
>
>    6.  Proxy: A peer or client that accepts SIP requests, resolves the
>        next hop or hops using the routing information of the P2PSIP
>        Overlay, and passes the request on towards the next hop.
>
> If the Proxy Peer is a *P2PSIP* Proxy Peer, that's fine - but what  
> should I
> call the node providing "Interaction with CS-SIP"?
>

Your understanding is consistent with mine. David's "adaptor nodes"  
are something else.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 4 Oct 2006 16:42:32 -0500

> thread, since UA Client C will be sending GET/PUT requests via  

I'd say "Proxy Peer Q" is something like a "P2PSIP Peer and Client  
Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy"

> functionality, and if I understood correctly, Eunsoo agreed.

I'd argue that those are added, but different, roles -- "P2PSIP Peer  
and SIP Redirector", P2PSIP Peer and SIP Registrar".

> to provide to the editors...

Yes. David has the master XML file now for the next revision.

>      |NAT|                                         |       |=====/  
> UA \
>        #                                           | Peer  |    | 
> ___C__|

--
Dean

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 04 Oct 2006 19:05:41 -0400

My comments are line.

>>call the node providing "Interaction with CS-SIP"?
In my understanding, Proxy Peer = Peer + SIP Proxy. Similarly  Redirect
Peer = Peer + SIP Redirect Server. The only difference between Proxy
Peer and plain SIP Proxy is that Proxy Peer understands the P2PSIP Peer
Protocol and Client Protocol in addition to the (plain) SIP protocol and
Proxy Peer can look up location information from the P2PSIP overlay
network using the Peer Protocol in addition to from DNS.

Proxy Peer understands CS-SIP messages and thus can interact with CS-SIP
nodes naturally.

So I am not sure whether we need any special node for interaction with
CS-SIP other than Proxy Peer and Registrar Peer (Peer + SIP Registrar).

>Your understanding is consistent with mine. David's "adaptor nodes"  
Is my understanding consistent with yours?

Thanks.

Eunsoo

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 5 Oct 2006 15:24:42 -0500

> Adaptor", whereas "Proxy Peer P" is a "P2PSIP Peer and SIP Proxy"

I would like to think that Spencer, Dean, David and Eunsoo are all talking 
about similar ideas using different words...

If I understand correctly, David and Eunsoo are thinking that a "Proxy Peer" 
would make a next-hop forwarding decision, which could be either to a 
conventional SIP next-hop or to a p2pSIP next-hop, while Dean is thinking of 
several flavors of "P2PSIP Peer AND" - SIP Proxy, SIP Redirector, SIP 
Registrar, and/or "P2PSIP Client Adaptor" (Dean did not use this exact 
phrase in his note).

Speaking only for myself, I've already gotten wrapped around the axle on 
"Proxy Peer". I'm not sure ANYbody made it most of the way to the bottom of 
https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-September/001386.html 
(my apologies, it was long), but anyone who did would have seen this 
conversation on 3.5.5:

>>> 3.3.5.  Bootstrapping
>>>
>>>    After discovering the address of a peer, the behavior of the 
>>> starting
>>>    node will vary depending on whether it is intending to be a peer  or 
>>> a
>>>
>>> Ouch - if I have a peer, I would think that I'm a peer, too. Is the 
>>> client
>>> actually discovering something like a "P2PSIP Overlay Server"?
>>
>> nope. It's discovering a P2PSIP Overlay Peer.
>
> I'm with you as far as the current text goes. What I'm trying to point out 
> is that there is nothing in the reference architecture that allows me to 
> distinguish between P2PSIP overlay peers that DO "serve" clients and peers 
> that do not. This seems to be a missing concept that I'd like to see 
> discussed.
>
> I seem to have confused more people than just Dean when I used the term 
> P2PSIP Overlay Server, but this captured what I was trying to say - the 
> P2PSIP Overlay is the resource, made up entirely of peers, and the client 
> wants a participant in the P2PSIP Overlay to allow an endpoint that is not 
> an overlay peer to store and retrieve information in the overlay.
>
> So, I'm thinking of a picture that looks like this
>
>   +---+          +---+---+      +---+
>   | p1|==========| p2| s5|------| c6|
>   +---+          +---+---+      +---+
>     #              #
>     #   overlay    #
>     #              #
>   +---+          +---+
>   | p3|==========| p4|
>   +---+          +---+
>
> Where p1,p2,p3,and p4 make up a P2PSIP overlay, c6 is the client that 
> wants to use P2PSIP resources, and s5 is the server entity that allows the 
> client to put and get P2PSIP Overlay entries without being a peer. There 
> is no "s5" in the reference architecture today. Today's picture would look 
> like this
>
>   +---+          +---+           +---+
>   | p1|==========| p2|-----------| c6|
>   +---+          +---+           +---+
>     #              #
>     #   overlay    #
>     #              #
>   +---+          +---+
>   | p3|==========| p4|
>   +---+          +---+
>
>>>    client.  If it is intending to be a peer, it goes into the P2PSIP
>>>    Overlay Peer Insertion process, at the conclusion of which it is
>>>    actively participating in the target overlay as a peer and is 
>>> capable
>>>    of routing requests and storing records on behalf of the P2PSIP
>>>    overlay.  If it is intending to be a client, it does not bother  with
>>>    insertion, but merely contacts the discovered peer in order to use
>>>    the overlay.

So, I think

+---+---+      +---+
| p2| s5|------| c6|
+---+---+      +---+

was the way I was drawing Dean's "P2PSIP Proxy AND Client Adapter" (p2/s5), 
and the P2PSIP Client (c6). I'm not suggesting this format, only hoping it 
helps describe what I'm talking about.

So the real question is, how much of this needs to be precisely described in 
the "concepts" draft? I'd really like to get the terminology down, but right 
now, I just need a suggestion about direction.

Thanks,

Spencer

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 5 Oct 2006 17:52:02 -0400

Spencer:
 
https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-September/001386.html <https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-September/001386.html> 
 
You are right that we have go to the bottom of this removing all technical confusions. Let me provide my suggestions how we can solve those logically step-by-step.
 
Let us consider the following Figure used in the discussion (a figure is a thousand words):

   +---+                  +---+---+      +---+
   | p1|========== | p2 | c5|---- | c6|
   +---+                  +---+---+      +---+
     #                         #
     #   overlay            #
     #                         #
   +---+                 +---+
   | p3|==========| p4|
   +---+                 +---+

This figure is the correct one because p1, p2, p3, and p4 use the same protocol and have the same functionalities.
 
The same is the case for c5 and c6.
 
However, p1/p2/p3/p4 and c5/c6 are different because the protocol and functionalities are different.
 
In the same way, the p2p-SIP concept draft needs to be re-written to reflect the description and figure with one-to-one mapping.
 
The problems with draft are as follows:
 
p2 and c5 entities have been merged into a "single entity" both in figure and in description while entities like p1/p3/p4 have also shown as a single entity both in figure and description. As a result, we know what has happened: A mountain of technical confusions.
 
Let the authors re-write p2p-SIP concept draft clarifying the things as described above with one-to-one mapping both in description and in figure leaving no room for any technical confusions. 
 
Best regards,
Radhika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061005/4ba7191b/attachment.html

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 5 Oct 2006 17:07:49 -0500

Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01Hi, Radhika,

In my limited understanding, c5 and c6 are actually acting as a server and as client, respectively - c6 would send PUTs and GETs to c5, and p2 would do insertions and retrievals into/from the overlay on behalf of c6, but c5 would not send PUTs to c6, because c6 is not a participant in an overlay.

So, if you're saying c5 and c6 know the same protocol, I agree, but I'm not sure whether you're also saying that the protocol between c5 and c6 is symmetrical. I thought it was asymmetrical - that's why I was trying to figure out where the "server" was, for the P2PSIP Overlay client.

Anyone can tell me I'm misreading the draft text, but that's what I was getting out of it.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Roy, Radhika R. 
  To: Spencer Dawkins 
  Cc: p2p-sip at cs.columbia.edu 
  Sent: Thursday, October 05, 2006 4:52 PM
  Subject: RE: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

  Spencer:

     +---+                  +---+---+      +---+

  Best regards,
  Radhika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061005/ef14d958/attachment.html

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 5 Oct 2006 19:58:54 -0400

Spencer:
 
I guess that we are in agreement. Let me explain the fact, even if there is p2p-SIP protocol, one acts as the server while other acts as the client and vice versa. In the case of CS-SIP, it is not the case. So, it is the protocol itself that will automatically determine who is what and when. 
 
However, the logical separation that I have generalized at a very high level is the very important first step for all of us to clarify. Then the second step will be to clarify further minor differences while using the same protocol by different entities. It is quite understandable.
 
More inline [RRR].
 
BR/Radhika

________________________________

From: p2p-sip-bounces at cs.columbia.edu on behalf of Spencer Dawkins
Sent: Thu 10/5/2006 6:07 PM
To: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

Hi, Radhika,

[RRR] Right. That is, they are communicating using the same protocol. In this way, they have same protocol functionality. If one is server or the other one is client, it is their behavior that may use differently, but the same protocol.

[RRR] Right. It is the same protocol that will derive the fact who is sever and who is client. The description in the draft will clrify the use case of the protocol for a given configuration further. The key is that the logical entitiies like c5-c6 can be used for any one of p1, p2, p3, or p4 for that matter.
 
[RRR] The other thing is this: For communications between p2 and c5, an interworking function (IWF) is needed. If both p2 and c5 are physically co-located, we may not need interworking protocol per se - an API may be good enough that may be defined at appropriate time. Otherwise, we may say that we will deal with this IWF later. In this way, we keep all the technical steps crystal clear without creating technical confusions as it is happening now.

[RRR] No, you are not mis-reading the draft. In fact, I would say that you have the third eye. This is what we expected when we would go for standardization of p2p-SIP.
 
Thanks,
 
Spencer

	----- Original Message ----- 
	From: Roy, Radhika R. <mailto:RADHIKA.R.ROY at saic.com>  
	To: Spencer Dawkins <mailto:spencer at mcsr-labs.org>  
	Cc: p2p-sip at cs.columbia.edu 
	Sent: Thursday, October 05, 2006 4:52 PM
	Subject: RE: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

	Spencer:

	 

	   +---+                  +---+---+      +---+

	 

	 

	Best regards,
	Radhika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061005/9ebbed17/attachment-0001.html

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 09 Oct 2006 01:34:23 -0500

> Registrar, and/or "P2PSIP Client Adaptor" (Dean did not use this exact 

Ok, let's explore my mental model of how I think P2PSIP works.

I presume that any P2PSIP peer will, if presented with a valid P2PSIP 
"get" or "put" request, either process the request, pass the request to 
another peer and stand by to return the result, or return a URI for 
another peer that the requestor should contact directly. Further, I 
presume that these operations happen at the level of the P2PSIP Peer 
protocol, which may well not be SIP. I further presume that every P2PSIP 
peer speaks the P2PSIP client protocol in addition to the P2PSIP peer 
protocol, assuming those are actually different protocols.

The above behavior is completely independent of SIP proxy, redirection, 
and registration server functions.

So, here are a couple of things I think result:what

1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP 
peer understand P2PSIP Client Protocol and will, if presented with a 
valid P2PSIP Client Protocol "Get" or "Put" request, do something 
reasonable with that request.

2) There are peers and/or clients in the P2PSIP world that also serve as 
SIP "server" nodes. These have  SIP proxy and/or SIP redirector (I hate 
the term "location server"), and/or SIP registrar functionality, and 
they use the data of the P2PSIP overlay to assist in responding to SIP 
request messages.

3) Most (ok,all) P2PSIP peers will act as either SIP proxy/registrar 
nodes or as SIP redirector nodes when presented with a SIP request that 
does not target the user of a UA colocated with that peer. Said 
otherwise, they either process SIP requests into the P2PSIP overlay, or 
they redirect them to another node that is expected to do the overlay 
processing needed to resolve those SIP requests.

--
Dean

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 9 Oct 2006 14:09:14 -0500

Hi, Dean,

> 1) There are no "P2PSIP Client Adaptors" because any and every P2PSIP peer 
> understand P2PSIP Client Protocol and will, if presented with a valid 
> P2PSIP Client Protocol "Get" or "Put" request, do something reasonable 
> with that request.

Far out. I am still absorbing an also-helpful previous note from you, so let 
me ask a question using that context.

>From a previous conversation:

>> - I'm very confused about how both clients and peers can be  "endpoints". 
>> For
>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I 
>> suspect
>> that this is conflating P2P endpoints (peers) with SIP endpoints  (either 
>> a
>> UA-peer or a UA-client). If you guys understand this perfectly,  please 
>> keep
>> typing...
>>
>
> Peers are supersets of clients. Everything a client can do, a peer  can 
> do.

Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP 
Overlay Client PROTOCOL?

Thanks,

Spencer

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 9 Oct 2006 15:21:53 -0400

I'll take a stab at answering Spencer's question...inline

> Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the P2PSIP

Logically, yes. However, because there has been hotly debated
discussion on which/neither/both are SIP, they may be syntactically
different, but yes, the set of things you can do in the peer protocol
is a superset of the things you can do in the client protocol.

David

> Thanks,
>
> Spencer
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Mon, 9 Oct 2006 16:12:24 -0400

Inline [RRR]

 
[RRR]  So, let make it clear separating into two: 1. Peer Protocol and 2. Client Protocol. In this way, we will remove technical ambiguities.

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061009/b8f5ec29/attachment.html

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 9 Oct 2006 16:22:08 -0400

Well, right now the draft does clearly distinguish the two, while
noting they may eventually be determined to be the same. I personally
am still an advocate of doing it all (client and peer protocol) in
SIP, in which case the two are one and the same.

David

On 10/9/06, Roy, Radhika R. <RADHIKA.R.ROY at saic.com> wrote:
> [RRR]  So, let make it clear separating into two: 1. Peer Protocol and 2.
> Client Protocol. In this way, we will remove technical ambiguities.
>
>
> David
>
>
> > Thanks,
> >
> > Spencer
> >

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Mon, 9 Oct 2006 17:46:22 -0400

It is true, but the draft is yet to clear as it is supposed to be.
 
Radhika

From: davidbryan at gmail.com on behalf of David A. Bryan
Sent: Mon 10/9/2006 4:22 PM
To: Roy, Radhika R.
Cc: Spencer Dawkins; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061009/617356f0/attachment.html

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 9 Oct 2006 16:50:46 -0500

OK, if we still need to have a more detailed discussion, I'll leave the 
pictures distinguishing between Overlay Clients and SIP UAs, with an option 
to remove this if SIP is used as the client protocol.

Thanks for the clarification.

Spencer

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 10 Oct 2006 11:27:56 -0500

> Do you see the P2PSIP Overlay Peer PROTOCOL as a superset of the  

No, I see the inverse -- the P2PSIP Client Protocol is a "functional  
subset" of the P2PSIP Peer Protocol. It may well also be a syntactic  
subset, or even the exact same protocolbut with some of it not  
exercised while in client mode.

In my world view, the "client" vs. "peer" role is ideally something  
that a node decides at run time based on its perception of current  
configuration, network reachability, and other operational constraints.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 10 Oct 2006 12:27:09 -0500

> configuration, network reachability, and other operational  

Well, that was a stupid response.

Yes, I see P2PSIP Overlay Peer Protocol as a superset of the P2PSIP  
Overlay Client Protocol. But while necessarily a functional superset,  
it may not be a syntactic superset -- it might be an entirely  
different protocol.

--
Dean

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 10 Oct 2006 12:24:44 -0500

Hi, Dean,

> subset, or even the exact same protocolbut with some of it not  exercised 
> while in client mode.

Based on your note (and David's note yesterday), I think the pictures I've 
been working on are OK for now.

> In my world view, the "client" vs. "peer" role is ideally something  that 
> a node decides at run time based on its perception of current 

This seems very reasonable, from the peer's perspective. The pictures I've 
been thinking of are most appropriate if the P2PSIP Overlay Client protocol 
is not a syntactic subset. We may have different ideas about when two 
protocols are "the same protocol" or not, but we don't have to figure that 
out until we have agreement on the functional subsetting.

Thanks,

Spencer

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 10 Oct 2006 12:32:40 -0500

Hi, Dean,

> Well, that was a stupid response.

It's been a long week here, too (and it's only Tuesday :-)
 
> it may not be a syntactic superset -- it might be an entirely  

Agree, and I'll leave the pictures in a state that allows this distinction.

Thanks!

Spencer

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 11 Oct 2006 15:08:40 -0400

A bit late, noticed a few things on a subsequent re-read here I wanted
to comment on. Inline...

> they use the data of the P2PSIP overlay to assist in responding to SIP

This is what I think of as an adaptor node. In my architecture, there
is only SIP. A regular P2PSIP Peer speaks SIP with P2P enhancements,
enough to be a P2PSIP Peer (process and store resources), but might
not support all the translating or processing of non-P2P SIP to
proxy/redirect it to the DHT for service. In my view of the world.
P2PSIP Client protocol is vanilla SIP. P2PSIP Peer Protocol is SIP +
P2P extensions. A given P2PSIP Peer may NOT be fully able to support a
connection from a non P2P aware client. It requires some extra logic
-- basically being a "translator" that recognizes the traffic is
vanilla SIP, and puts in the P2P content and sends it along. It might
need to keep state for that vanilla node even. Not every P2PSIP Peer
may implement or want to provide that. Those that do will logically be
P2PSIP Proxy or P2PSIP Redirect peers, and in my mind are adaptor
nodes. Your assessment below is right, I just don't expect every node
will implement that behavior.

--David

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 11 Oct 2006 12:43:29 -0700

Folks,

We have to prepare a hum vote on the decision on what the p2p protocol
should be:

1. Chord, Bamboo, etc.,
2. SIP as David argues here,
3. Open for flexibility to accommodate future P2P protocols.

This will not be an easy decision.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
Sent: Wednesday, October 11, 2006 12:09 PM
To: Dean Willis
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

On 10/9/06, Dean Willis <dean.willis at softarmor.com> wrote:
> Spencer Dawkins wrote:
> >>> I'm explicitly showing a proxy that provides overlay clients
access  to
> >>> the
> >>> thread, since UA Client C will be sending GET/PUT requests via
unicast
> >>> to a

--David

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 11 Oct 2006 16:06:09 -0400

I don't think those decisions will be made at the BOF. The Charter is
designed to leave that open, but of course, it will be one of (if not
the first) important questions that the (hopefully!) newly formed WG
will make as a group.

David

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 11 Oct 2006 18:27:50 -0400

> This will not be an easy decision.

Are these really the right choices?
Chord, Bamboo, etc are DHT algorithms, while SIP is a signaling  
protocol,
so I don't think it is an either/or choice.

David's draft, for example, uses SIP as the protocol for carrying the  
P2P messages,
while implementing a Chord DHT.

We could imagine an alternative protocol that was (say) XML-based for  
encoding the P2P message,
while still using Chord as the DHT.

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 11 Oct 2006 18:38:28 -0400

One of the problems with the Concepts draft right now is that a lot  
of aspects
of the design are not decided upon, so the draft needs to be rather  
vague in
a number of places.

For example, the proposed WG has not yet decided if the protocol will  
be based
on a DHT lookup algorithm or some other algorithm, so the draft needs  
to use
language that accommodates both choices.

As another example, the proposed WG has not decided what the format  
of protocols
would be, so the distinction between SIP UAs, Clients, and Peers are  
not as crisp
as they might be.

One option might be to provide one or two concrete examples of how to  
instantiate
the concepts in the draft, either in the document itself or in  
separate documents.

- Philip

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 11 Oct 2006 19:25:42 -0400

A P2P algorithm (like DHT) can be tunneled over SIP messages in the
same way PPP can be tunneled over Ethernet.  This allows two DHT
realms to form a union over a common signalin protocol via a
super-peer that understands the babel.  I'm not sure which algorithm
will be used most in practise but it may not be for us to decide which
is best given the applications that will come down the line.

A careful choice will allow:

1. Signalling that declares the P2P algorithm in use.
2. The ability to nest (or tunnel) P2P algorithms over each other.
3. The ability to define hash table characteristics. Some algorithms
will prefer to have complete tables noisily updated with all members.
Others will have more sparse tables that have the potential for many
hash collisions. Each have their reasons.

I suspect that we will choose two or three well-known algorithms to
start. Some smart effort will not limit us to these choices or to
non-recursive algorithms.

Regards

M

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 11 Oct 2006 16:44:00 -0700

> is best given the applications that will come down the line.

I don't understand how you expect this to work with DHTs that
implement different algorithms/topologies. How are you going
to have a "union" of Chord and CAN, for instance?

At a more meta-level, it seems to me that carrying the intra-DHT
messages over SIP has a number of disadvantages and very few
advantages.  First, it imposes a very substantial burden on any other
IETF protocol that wants to use DHTs--you have to implement SIP!
Whenever possible, one should try to build generic tools.  Second,
it's not like the semantics of SIP messages aren't a particularly
good fit for DHT maintenance messages. You'd just be picking some
arbitrary SIP message and stuffing the upper-layer protocol in
it. What's the advantage of this?

-Ekr

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 12 Oct 2006 06:40:49 -0400

>to have a "union" of Chord and CAN, for instance?
Salman, Henning and I looked into the possibility of forming a "union"
of different DHT algorithms(networks). So far it seems difficult if not
impossible.

>it. What's the advantage of this?
Therefore, I think we need to roughly define what fields the DHT
protocol messages should carry and compare candidate base protocols (eg.
SIP, SOAP, or any other) about how the fields can be carried by each
base protocol. Certainly this should be a task for the (future) WG.

Thanks.

Eunsoo

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 12 Oct 2006 12:13:36 -0400

> base protocol. Certainly this should be a task for the (future) WG.

Absolutely.  But bear in mind that the fields that will  be carried
will be highly context-dependent and these fields will evolve over
time.

There may be one of many possible DHT choices each supporting a set of
objects  that they can carry.  In the OO age it may be better to refer
to objects and not fields.  Some of these objects will have more
sticky definitions than others. Others will be overloaded depending on
the application or network at hand.

In that case while the base messaging protocol would be common the
objects carried by the protocol become far more open.  Some common
elements must of course exist, so part of the protocol definition
should mandate that all mandatory base common elements still appear if
a field/object is overloaded with a new object definition.

---

From: br at brianrosen.net (Brian Rosen)
Date: Thu, 12 Oct 2006 13:51:24 -0400

I agree that we have separate choices:
1. We choose a DHT for the "mandatory to implement" mechanism
2. We choose two protocols

"Choice" implies there is more than one proposal
"Proposal" implies there are documents to define a proposal

So, although the document we care about right now is the charter (and PLEASE
comment on anything you don't like now, or be prepared to humm in favor of
it at the BoF), I don't really see any proposals on the table to make
choices from.

I don't consider a simple email like "I want to use Chord" a proposal.
Write up a draft about WHY <insert your favorite DHT> is the best choice for
p2psip.

Also, note that we are talking in terms of "which DHT".  That implies the
p2p basic mandatory to implement algorithm IS A DHT.  If that is not your
intention speak now.

Brian

> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Philip Matthews
> Sent: Wednesday, October 11, 2006 6:28 PM
> To: Henry Sinnreich
> Cc: P2P-SIP

---

From: br at brianrosen.net (Brian Rosen)
Date: Thu, 12 Oct 2006 13:58:59 -0400

We agreed at the last BoF that we would choose ONE mandatory-to-implement
DHT.  That guarantees interoperability of implementations.  Other algorithms
can also be implemented.  That possibility implies there is a way to
discover which algorithms a domain implements.

That leads me to a question.

I understand Mandatory-To-Implement.  It means that a piece of code is
guaranteed to work with any other piece of code if the DEPLOYMENT decrees
that the mandatory to implement part is used.  In this case, it means that
within a p2p domain, if the chosen DHT is deployed, every client will be
able to work.

If another DHT is deployed, some clients may not work.

Is that the end of the discussion, or is there a possibility to make things
better?  For example, is there any sensible way to run more than one DHT
simultaneously with some kind of shared state?

Brian

> bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
> Sent: Wednesday, October 11, 2006 7:26 PM
> To: Philip Matthews

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 12 Oct 2006 14:51:18 -0400

> discover which algorithms a domain implements.

Good.

I agree that one base DHT must be there and fully supported as per
mandatory in the spec by all nodes.  It solves the critical first
problem: Connecting the members of the network, with some form of base
(ultimately canonical) identification.

Then what? Now that we're connected, what's next?

For example: Let's say I want to "send 10 whuffies" from my bag of
whuffies to Ensoo''s bag of whuffies, but I've got a Microsoft P2PSIP
whuffie-bag while Ensoo has a Pansonic P2PSIP whuffie-bag. What's
worse is that my whuffies are Canadian in French while Ensoo's is
American and in English, and the rules of the network is that the
network gets a 2% whuffie transfer surcharge to pay for its
operations, the current instantaneous settlement exchange rate is 0.90
Canadian Whuffies to the US variety, and my government charges 6% GST
for the transaction Just Because It Can.

I very much doubt that a Whuffie Definition (P2PSIP-WHUFFIE) will make
the first spec. But I sure hope that the first cut of the object/field
definition of the DHT does not preclude any FUTURE possibility for a
Whuffie Definitions and Mechanisms For Peer To Peer SIP
Internet-Draft, and not the April 1st variety.

For the uninitiated, more on Whuffies here:
http://en.wikipedia.org/wiki/Whuffie

It would be a heck of a whole lot easier to implement an object
extension to the current DHT than to implement a whole new DHT with
new and different objects, and it would be even better if these
objects were true objects and not fields.

Interoperability is far more likely if it is easy to extend a
well-defined DHT protocol.

But I suggest that as protocol developers a hook be put in making it
MANDATORY that any such extensions use well-understood, broadly
implemented and well-documented means (including as a start the
MANDATORY 'hello, object extensions to this DHT protocol exist, these
are they, and they are defined 'here') much like we see with protocols
like SMTP and HTTP.

If the DHT mechanism doesn't satisfy these requirements a different
DHT >may< be used for the purpose of the application (one nefarious
non-scalable but I suspect pending rule may be 'no hashes allowed,
only complete tables containing all members, but only for members
supporting paranoid application type X), but it should not preclude a
MANDATORY that such a DHT extension also carry an equally
well-understood, broadly implemented and well-documented DHT
definition not covered by an NDA, if it is to be considered
interoperable P2PSIP. (Mil-Spec Seekrit DHT's can of course ignore
this as they always do)

If the existing DHT allows objects to be inserted in its list of
fields, this would mean that any other DHT will only be used if the
existing DHT is not up to the job, which would reduce such occurances
to 1.) exception cases where it does not meet the requirements and 2.)
competitive reasons to bury key features within proprietary
extensions.  The latter becomes somewhat more difficult if any
proprietary extension must describe itself if the implementation has
claims to be standards compliant, and that a rule of the protocol is
that seekrit undocumented extensions are always verboten.

Given that, I suspect the number of cases based on real technical
limitations will be rare, meaning that other DHT types will only be
used per regulatory fiat or per typical behavior of a large dominant
vendor. You still will have vendors thumbing their noses at true
compliance, but at least you have a strong contract to point to rather
than a weak document with too much wiggle room.

Regards

Michael

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 16 Oct 2006 16:14:01 -0700

The Internet Draft "Lightweight SIP Toolkit for P2P and Basic CS
Systems" has been posted by the IETF:

http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-00.txt  

The I-D is also available at p2psip.org 

     The number of SIP related standards can be significantly 
     reduced for various application scenarios by (1) using SIP 
     without "network based services" and (2) without emulating the 
     telephone network.  

     Such an approach reduces the number of SIP related standards 
     (as by mid 2006) from roughly 100 to about 11. Core SIP 
     interoperability and SIP compliance can be preserved without 
     relying on complex server based networks. 

     Successful IP communications must also include the relevant 
     standards for NAT traversal, some of which are not directly 
     related to SIP and also several standards for security. These 
     standards are included here as well.

Any suggestions and your FRANK opinion would be most welcome. 
Please use the list.

Thanks, Henry

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 17 Oct 2006 12:33:41 -0500

Sorry for not sending this sooner. But...

I'm really pleased with the changes that are now in 02. (although we might 
reasonably change some terminology when we make some decisions that are 
still open issues now, and I'm not totally sure *I* understand what an 
endpoint is).

Just for completeness, I compared my notes on the previous version against 
02. Many were addressed, so I deleted those comments from the list shown 
below - anything remaining is still something I'm wondering about.

Please note that several of my notes are from the section on open questions, 
and I'm ok with these questions being open at charter time.

Thanks,

Spencer

>   P2PSIP Overlay Bootstrap Server:  A network node used by P2PSIP
>      Overlay Peers or Clients who are attempting to enter to locate an
>      entry into the P2P Overlay Network.  It may return an entry point
>      (address of a Peer) to the P2PSIP Overlay or act as one itself.
>      This should be a quasi-stable and well known host, located using a
>      configuration or discovered via , DNS, broadcast, or other
>      mechanism.  Example: a P2PSIP Overlay Peer that reboots and has no
>      knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to
>      find other peers in the P2P Overlay Network and establish P2PSIP
>      Overlay Peer Insertion.  (Note: An overlay peer might or might not
>      provide this functionality).  Short forms: bootstrap server, boot
>      server.
>
> These short forms seem very likely to conflict with lower-layer usage of 
> the
> same terms, where "bootstrap server" and "boot server" have a
> well-understood usage. "Overlay bootstrap server" as short form?

This is now "bootstrap peer". That's an improvement.

> 3.3.  Conceptual Outline of Operations
>
> 3.3.1.  Enrolling and Inserting an P2PSIP Overlay Peer
>
>   Peers are the full-function "routing and storage" nodes of a P2PSIP
>   Overlay.  When a new peer is first created, it must enroll in the
>   P2PSIP Overlay.  We currently have no defined mechanism for this (do
>   we need one?), but we know that once the process is complete, the new
>
> I think this is required for the ad hoc scenarios, isn't it?
>
>   peer will have at least a P2PSIP Overlay Peer Key and a set of
>   credentials.

This is now in section 3.4.1, and has changed, but still says

   Peers are the full-function "routing and storage" nodes of a P2PSIP
   Overlay.  When a new peer is first created, it must enroll in the
   P2PSIP Overlay.  We currently have no defined mechanism for this
   (should this group define one?),

I would like stronger text, something like "and this is required for P2PSIP 
interoperation in at least some scenarios". The current text allows us to 
say "no, it's fine for us to leave this to vendor-specific operation", so 
users would have to use the right vendor's product to participate in the 
overlay - this is a big deal, but it's a bigger deal for ad hoc scenarios 
where you could walk into an overlay using enrollment from any vendor.

> 3.3.2.  More on The Difference Between a Peer, Client, and User Agent
>
>   P2PSIP Overlay Peers directly interact with and contain the routing
>   and storage fabric of the overlay.  P2PSIP Overlay Clients just use
>   the routing and storage facilities provided by the peers.  The peers
>   speak the P2PSIP Overlay Peer Protocol, which presumably has a full
>   range of expressivity for the routing and storage facilities of the
>
> "expressivity" is a great word. Is it defined anywhere? ;-)

Dean pointed out that expressivity is a real word, but I still struggling 
with the usage here. "Functionality"?

>   overlay.  Clients speak the P2PSIP Overlay Client protocol, which is
>   presumably a subset of the peer protocol, and is limited to storage
>   insertion (put), storage retrieval (get), and message routing (send).
>
> 3.3.3.  Enrolling a User and Inserting a P2PSIP Overlay User Agent
>
>   To get started, users must be enrolled in the overlay.  We do not
>   have a process or protocol for this, nor are we certain we need a
>   standardized mechanism.  We presume that after enrollment, the user
>   has a distinguished name within the overlay (example:
>   sip:bob at example.com) and a set of credentials useful for
>   authenticating its usage of the distinguished name.  One possible
>   mechanism for these credentials would be an x.509 certificate.  It
>   might also be possible to use a PGP key, a password, or some other
>   mechanism.  Presumably following enrollment, the user is also
>   equipped with the information needed to connect to the overlay, such
>   as the address of a bootstrap server.  Whether this startup
>   information is delivered as a part of enrollment of through some
>   separate configuration process remains an open question.
>
> I would like to define this, but am concerned that the choice may differ
> per-overlay. Do others agree?

The text moved to 3.4.3, and changed in 02. It is now

   Whether this startup
   information is delivered as a part of enrollment of through some
   separate configuration process remains an open question, and it is
   not clear it is within the scope of the proposed WG.

I would be concerned if at least the requirements for enrolling and 
inserting users are out of scope for P2PSIP. Is this text saying that P2PSIP 
might not be chartered to develop the mechanism (I could agree) or that 
P2PSIP might not be chartered to specify requirements for this mechanism, 
whether it is developed in P2PSIP or in another appropriate working group 
(this is harder to accept)?

> 3.3.5.  Bootstrapping
>
>   If a client or peer is just starting up and has no knowledge of how
>   to reach the other nodes of the overlay, it may exercise a bootstrap
>   server to find one.  Presumably it discovers the bootstrap server by
>   some mechanism such as a DNS lookup, multicast, broadcast or
>   configuration, then queries the bootstrap server and receives an
>   address for a peer or set of peers that can be used to reach the
>   overlay.  Ideally, these target peers will be selected from a
>   relatively large pool of peers that are currently online and
>   reachable.
>
> This last sentence seems awfully use case-specific, doesn't it?

This text is now in 3.4.5, but hasn't changed. The point I was trying to 
make in my notes was made more clearly by David Bryan in an e-mail onlist:

"One of the many reasons I am so keen on using pure SIP for the client 
protocol is that if one bootstraping peer is overloaded, it can simply 302 
(or perhaps 301 if it wants this requestor to keep using another peer) 
incoming requests off to a less loaded peer."

I think what the paragraph SHOULD say is, "Ideally, P2PSIP will allow target 
peer selection in a way that allows recovery from overload situations".

> 4.9.  Cryptotransparency
>
>   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 believe this question is key when we discuss what an endpoint is (see
> previous comments on whether clients are endpoints).

This is now 4.6, but hasn't changed in 02. I am still confused about the 
expected trust model in a peer/UA-to-peer/UA dialog versus a 
peer/UA-to-peer/UA-to-client/UA dialog (assuming that there are only two 
endpoints of the trust relationship, does the first peer/UA NOT trust the 
second peer/UA, or does the first peer/UA NOT trust the client/UA?

I don't think we have to know the answer to this question to charter the 
working group, but I think we need to agree on whether it's an interesting 
question or not.

> 4.13.  Bootstrapping
>
>   We know that sometimes peers or clients will start up without
>   knowledge of how to find a peer for insertion.  Do we need to define
>   a bootstrap mechanism or mechanisms?  Do we need to define supporting
>   protocols?
>
> I believe the answer to both of these is "yes" to support anything like ad
> hoc use cases.

This is now 4.10, but the text has not changed. Again, I would like stronger 
text, something like, "Do we need to define a bootstrap mechanism, or 
mechanisms, and do we need to define the supporting protocols? If P2PSIP has 
interoperability except at boot time, this means P2PSIP does not have 
interoperability." Or something. Mumble.

> 4.16.  Hybrid Domains
>
>   It appears possible to have some hosts within a domain using
>   conventional SIP and some using P2PSIP.  This potentially raises a
>   number of questions: 1) What should happen if we want to run a P2PSIP
>   overlay in an existing SIP domain? 2) Do the existing redir/proxy
>   servers need to be coupled with a peer layer? 3) When would an
>   overlay peer want to discover them as opposed to looking in the
>   overlay? 4) Is better not to run conventional SIP with overlay SIP?
>   5) When conventional and P2PSIP are run together, shall the existing
>   redir servers keep their local databases or switch to the overlay
>   storage.
>
> We've had some discussion on-list here about whether I have the same AOR 
> in
> conventional SIP and P2PSIP overlays or not. Did we converge?

Dean says, and I agree, that we have not converged. This text is now 4.13, 
but has not changed. Could we add a note something like

"One related question is whether a UA could use the same AOR in conventional 
SIP and in P2PSIP. This isn't known yet, and the answer affects the ability 
of P2PSIP to support "hybrid domains"

?

---

From: arjun.lists at hsc.com (Arjun Roychowdhury)
Date: Tue, 17 Oct 2006 13:58:55 -0400

Henry,
Comments:

* I find the title of the draft confusing. It seems to be a first step
in trying to put one's arms around what is the minimal feature set of
SIP we need for a P2P system and what architectural assumptions we
may/may not make - to that extent not sure 'tools' fit in at all, more
like 'minimal architecture and feature assumptions for P2P SIP' -
actually it sounds very much like a subset profile, though you
explictly state it is not (why ?)

* 2.b) .
"Analyze the main SIP related specifications as highlighted in [14]
and eliminate all network based services residing in servers and
various other network        elements. "

You need to either specify what you mean by "network based services"
concretely, or drop this term, since later you state that Locating SIP
servers is a 'core requirement' - location/routing is also a network
based service.

* You may need to add a section on interoperability with nonp2p SIP
networks - what are the assumptions, who you delegate the role of
interoperability to etc.

regds
arjun

-- 
Arjun Roychowdhury

---

From: swb at employees.org (Scott W Brim)
Date: Tue, 17 Oct 2006 14:47:52 -0400

> Sorry for not sending this sooner. But...

I thought I was way late with my comments so I just sent them to the
authors.  They're small but I'll post them after this.

>    Peers are the full-function "routing and storage" nodes of a
>    P2PSIP Overlay.  When a new peer is first created, it must enroll
>    in the P2PSIP Overlay.  We currently have no defined mechanism
>    for this (should this group define one?),
> 
> I would like stronger text, something like "and this is required for
> P2PSIP interoperation in at least some scenarios". The current text
> allows us to say "no, it's fine for us to leave this to
> vendor-specific operation", so users would have to use the right
> vendor's product to participate in the overlay - this is a big deal,
> but it's a bigger deal for ad hoc scenarios where you could walk
> into an overlay using enrollment from any vendor.

Regarding peer enrollment and user enrollment (below).  Enrollment is
completely separate from the actual functioning of the P2P system, so
if we specify anything it should not be more than a default -- for
example configuration.  There are so many possible mechanisms.  

> >   the routing and storage facilities provided by the peers.  The
> >   peers speak the P2PSIP Overlay Peer Protocol, which presumably
> >   has a full range of expressivity for the routing and storage
> >   facilities of the
> >
> Dean pointed out that expressivity is a real word, but I still
> struggling with the usage here. "Functionality"?

Simplest would be "has a full range of capability for expressing the
routing and storage ...".

Scott

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Tue, 17 Oct 2006 18:17:49 -0700

Arjun,

> what is the minimal feature set of SIP we need for a P2P system and
what 
> architectural assumptions we may/may not make

This is good point - we will cover in the next version.

>You need to either specify what you mean by "network based services"

This is also a good point since what is meant by "network based"
services needs some examples, such as voice mail, conferencing, (hosted)
PBX functions. Maybe an acceptable definition is "anything else but a
proxy/redirect SIP server" since these functions are basically message
routing functions only.

> networks.

The above could also take care of p2p-cs interoperability.

Thanks for the comments,

Henry

-----Original Message-----
From: arjunrc at gmail.com [mailto:arjunrc at gmail.com] On Behalf Of Arjun
Roychowdhury
Sent: Tuesday, October 17, 2006 12:59 PM
To: Henry Sinnreich
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS
Systems

Henry,
Comments:

* 2.b) .

regds
arjun

-- 
Arjun Roychowdhury

---

From: petithug at acm.org (Marc Petit-Huguenin)
Date: Wed, 18 Oct 2006 13:25:19 -0700

Hi Henry,

I like your I-D a lot.  I think that it is time for SIP to go back to a 
strong support of the end-to-end principle, and to clearly indicate to 
implementors what part of SIP is SIP, and what part is for supporting 
legacy systems (PSTN, IMS, etc...).

This remind me of what was done ten years ago for movies, when 
independent filmmakers defined Dogma 95[1] as a set of rules to purify 
movie making. I see a lot of parallels, so I am proposing the name 
"Dogma 06" for this effort to purify SIP.

Thanks.

[1] http://en.wikipedia.org/wiki/Dogma_95

-- 
Marc Petit-Huguenin           [                                 ]
Home: marc at petit-huguenin.org [  This RFC1855-compliant space   ]
Work: marc at 8x8.com            [           for rent              ]

---

From: edpimentl at gmail.com (Ed Pimentel)
Date: Wed, 18 Oct 2006 17:25:10 -0400

This is a case when "perfect" is not good enough.
We all recall the failure of X.400/500 and a more pragmatic/workable  
solution LDAP has provided
Or the failure of OSI - NMS and how SNMP came to the rescue.

What we need now is a SSIP a SIMPLE Session Initiation Protocol that  
simply just works and does not try to replicate the CLASS5 Services  
but in turns
innovates with what I call CLASS 6 Services....
Where as CLASS 5 services schackled you to the black 2500 ma-bell  
phone....
  Class 6 cuts the unbilical chords and innovates by providing beyond  
voip services that are not necessarily to the PSTN/SS7/IN/SCP network.

-E

---

From: petithug at acm.org (Marc Petit-Huguenin)
Date: Wed, 18 Oct 2006 15:18:18 -0700

Ed Pimentel wrote:
> simply just works and does not try to replicate the CLASS5 Services but 
> in turns

Excepted that the IETF work is "above the wire and below the 
application."  I think that the proposal of Henry and the other authors, 
to do not define another SIP but just define the subset of SIP to use, 
is the way to go.  Let's the implementors do not have to juggle with 
100+ RFCs and I-Ds and let them design the services that the PSTN/IMS 
will be jealous of.

Well, this said, I would be happy if the B2BUA definition can be removed 
from RFC 3261.  And all the SHOULD rewritten to MUST.  And adding a 
sentence that makes fun of SBC.

But I am a reasonable person.

> Where as CLASS 5 services schackled you to the black 2500 ma-bell phone....

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 18 Oct 2006 15:33:29 -0700

> sentence that makes fun of SBC.

B2BUA is for those who are incapable of taking on a feature-enriched service
through light-weight approaches (eg. by means of a transaction-stateful
proxy seasoned with just a little dialog-statefulness).

If I may add, the sentence to make fun of SBC is "SBC is redundant and made
only by those who cannot find position either on CPE or on Softswitch
market." Even the regulated Lawful Interception by 2007 can be without SBC.

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 19 Oct 2006 15:01:31 -0400

> 100+ RFCs and I-Ds and let them design the services that the PSTN/IMS

This is a perfect description of the problem being solved.  Thank you.

SIP as it stands is immensely powerful but is being obscured by
arcana.  It is vital that application developers have invariant common
reference descriptions so they know what the foundations are and trust
that those underpinnings are there.

The draft starts us on a path that leads towards an open common
communications platform that application developers can depend on.

> Well, this said, I would be happy if the B2BUA definition can be removed

A B2BUA is useful in  many technical circumstances.  My employer uses
one such B2BUA in order to map a proprietary identity and authority
regime with those of SIP and the public Internet. It solves many
problems, and as long as these  requirements are easily met our
customers are happy.  E2E is not one of these requirements. Far from
it.
They firewall/NAT up the wazoo and each circumstance and
implementation is different.

The B2BUA definition allowed SIP to be revolutionary enough to not
scare the pants out of the people who want their revolutions to be
easy and on their terms.  It allowed SIP efforts to get green-lighted
and budgeted by people who would otherwise have waved it off as too
bleeding edge. It gave systems that were long in the tooth before they
were even born a new lease on life. It was the B2BUA definition made
SIP safe for the boardroom.

It is like NAT in that manner. But like NAT the B2BUA genie is now out
of the bottle.
It got us here but it won't go away now that it is a problem.

The answer?

Make the B2BUA genie a non-issue with applications that can traverse
any B2BUA in the same way that Skype turned NAT a non-issue.

My Irish Wolfhound can jump any walled garden.   Whomever slays the
B2BUA genie becomes the next Skype.

>  And all the SHOULD rewritten to MUST.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Complete total utter agreement.  It is the essential problem that is at hand.

Henry, Alan and Kundan: Well-done.

Regards

M

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 19 Oct 2006 15:08:22 -0400

Ensoo too, of course. Forgive me for my initial omission.

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Sun, 22 Oct 2006 14:46:56 -0400

Hi Spencer:

I have addressed some of your concerns.
See inline.

- Philip

> This is now "bootstrap peer". That's an improvement.

As previously discussed, the document now make a distinction between
a bootstrap peer and a bootstrap server.

>> (do

Scott expressed some concerns with this, so I have just left this alone
for now.

>> peers

The sentence now reads
            The peers speak the P2PSIP
	    Peer Protocol, which can express all the necessary routing and  
storage operations
             required for the overlay.

> (this is harder to accept)?

This seems to be more of a charter issue than a document issue.
I suggest bringing this up at the BOF.

> peer selection in a way that allows recovery from overload  

I have rewritten this section in light of the distinction between  
bootstrap peers
and bootstrap servers. There is now a sentence that reads:
		Ideally, the mechanism for locating a bootstrap peer and handling a  
new peer or client
		will attempt to distribute the load evenly across the various nodes  
involved.

> working group, but I think we need to agree on whether it's an  

I decided not to try to tackle this one in the -03 rev. Sorry.

> interoperability." Or something. Mumble.

I have also rewritten this section.  It now reads:
	  We know that sometimes peers or clients will start up without  
knowledge of how to
           find a peer for insertion. In this case, what is the  
mechanism that a new peer or client uses to find
	  a P2PSIP Bootstrap peer?

> of P2PSIP to support "hybrid domains"

I added the sentence:
	  A related question is whether a UA could use the same AOR in  
conventional
	  SIP and in P2PSIP?

- Philip

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Sun, 22 Oct 2006 21:30:23 -0500

Hi, Philip,

> I have addressed some of your concerns.

Most, I think (and it's not like the remaining concerns needed to be 
addressed in 03, either). Thanks for the work you did this week and weekend 
supporting the 03 revision.

See inline.

> a bootstrap peer and a bootstrap server.

I recognize that we are still in mid-thought here, but I'm still happy with 
where we are.

>> P2PSIP

Looking back onlist, I saw Scott's note that said

> example configuration.  There are so many possible mechanisms.

I think Scott and I are in rough agreement here, we just ran out of time 
before the I-D cutoff, or we would have closed this one. I think we should 
specify a default, but there is no expectation that one size fits all, or 
even most - I agree, and don't think this will be a problem.

>             required for the overlay.

Thanks - works fine for me.

> I suggest bringing this up at the BOF.

Umm, yeah. The document is talking about charter scope, which is slightly 
circular, and I'm also thinking you couldn't have fixed it yourself by the 
ID cutoff, so you made the right call.

> Ideally, the mechanism for locating a bootstrap peer and handling a  new 
> peer or client

After all of us have a chance to look over the revised draft, I'd suggest 
removing "evenly", but this is definitely headed the right direction. Again, 
thanks.

> I decided not to try to tackle this one in the -03 rev. Sorry.

Again, I don't see how you could have fixed this one on your own. During the 
telechat last week, I asked for, and got, assurances from people on the call 
that we can figure out how the trust relationship really works when we have 
a peer/UA communicating with a client/UA through a peer. Given that, we 
didn't need to work this out before chartering (don't need to solve the 
problem, just need to know it's solvable). You made the right call.

>   We know that sometimes peers or clients will start up without  knowledge 
> of how to
>           find a peer for insertion. In this case, what is the  mechanism 
> that a new peer or client uses to find
>   a P2PSIP Bootstrap peer?

Captures my question. Thanks. When the draft cools off, we might 
s/sometimes/in some scenarios/, but this is good enough for now.

>   A related question is whether a UA could use the same AOR in 

Captures my question. Thanks.

---

From: swb at employees.org (Scott W Brim)
Date: Mon, 23 Oct 2006 05:37:27 +0200

Excerpts from Spencer Dawkins on Sun, Oct 22, 2006 09:30:23PM -0500:
> > Regarding peer enrollment and user enrollment (below).  Enrollment
> > is completely separate from the actual functioning of the P2P
> > system, so if we specify anything it should not be more than a
> > default -- for example configuration.  There are so many possible
> > mechanisms.
> 
> I think Scott and I are in rough agreement here, we just ran out of
> time before the I-D cutoff, or we would have closed this one. I
> think we should specify a default, but there is no expectation that
> one size fits all, or even most - I agree, and don't think this will
> be a problem.

If I hadn't run out of time myself I would have gone further and
suggested that the text about minimum capabilities of the peer and
client protocols should not include enrollment, since it could be
completely orthogonal.  

See you soon ... Scott