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

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 7 Sep 2006 14:58:00 -0500

I'm trying to get through this document at several levels - I hope these 
comments are coherent (and helpful).

Summary - the document is really a good start, even though I have lots of 
notes and suggestions. Thanks for the hard work.

Thanks,

Spencer Dawkins

High-level comments ...

- in general, I'd like to tighten up the terminology that we use. There are 
terms with four additional "short forms" listed. This seems unnecessarily 
confusing. It is OK to have a short form, but can we deprecate at least some 
of the choices?

- as a follow-on, it's not clear to me how much of the terminology is P2PSIP 
and how much is P2P in general. For example, is there anything special about 
a "P2PSIP Overlay Key", compared to an "overlay key"?

- Figure 1 seems confused on whether the UA/Peers behind the NATs are part 
of the overlay or not - I think I can draw the lines more clearly (shown 
below), assuming that they ARE part of the overlay.

- Figure 1 is also trying to do more than you can do in ASCII art (at least 
I think so) - the dotted lines either mean (a) logical connectivity in the 
overlay, (b) physical connectivity through the NATs, or (c) a SIP call. I 
doubled the lines for the overlay topology, but left the SIP calls in and 
don't like the result. If people agree, I can do ASCII art for (a) and (c), 
as two figures.

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

- I'm somewhat confused about how we can talk about P2PSIP peers and clients 
without talking about something like a P2PSIP Overlay Server (see comments 
below).

Detailed comments ...

2.  Definitions

   P2PSIP Overlay User Agent:  A SIP user agent that is coupled to a
      P2PSIP Overlay Peer or P2PSIP Overlay Client, such that the peer
      or client can assist the UA with registration (storage of a route
      to users of the UA) and/or routing of requests using the P2PSIP
      Overlay.  A P2PSIP Overlay SUer Agent differs from a conventional

s/SU/Us/

      SIP user agent in that it is coupled directly to a P2PSIP Overlay
      Peer or P2PSIP Overlay Client, and can therefore directly interact
      with a P2PSIP Overlay, which a conventional SIP UA cannot do.
      P2PSIP Overlay User Agents are presumed to have no distinguished
      name or identifier.  Short forms: overlay UA, P2PSIP UA.

   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?

3.  Discussion

3.1.  What Kinds of P2PSIP Overlay Peers and Clients Might Exist?

   3.  Gateway: a peer or client that converts from P2PSIP to some other
       protocol, such as PSTN.

"PSTN" should be expanded on first use. It is expanded, but not on first 
use.

   4.  Redirector or Location Server: a peer or client that, given a SIP

Is this a "SIP INVITE", or something else? looks like a cut and paste error.

       (or other SIP request) to a P2PSIP overlay resource identifier,
       returns the route to a resource in a 302 or 305 response.

3.2.  Reference Model

Note - this is my redrawn picture, with changes on the left...

                                            --->PSTN
                                -----------/
    --------        |N|        | Gateway |
    |      |========|A|========|   Peer  |==============
    |  UA  |        |T|        |         |             ||Client Protocol
    | Peer |                   -----------             ||  GET/PUT
    |  C   |                                           ||  |
    --------                                           ||  |   \__/
       ||                                              ||  v   /  \
      |NAT|                                            ||---- / UA \
       ||                       P2PSIP Overlay         ||    /Client\
       ||                                              ||    |______|
       ||                        Route Data            ||        ^
    --------      --------                             ||        |
    |      | |N|  |      |                             ||        |
    |  UA  |=|A|==|  UA  |                             ||        |
    | Peer | |T|  | Peer |                             ||        |
    |  D   |      |  E   |                             ||        |
    --------      --------                             ||        |SIP
        Peer Protocol ||  ---------        ---------   ||        |
                      ||  |       |        |       |   ||        |
                      ====| Proxy |========| Redir |====         |
                          | Peer  |        | Peer  |             |
                          |       |        |       |             |
                          ---------        ----------            |
                         /                         \            /
                        /                           \          /
                 \__/  / SIP                     SIP \  \__/  /
                  /\  /                               \  /\  /
                 /  \/                                 \/  \/
                / UA \                                 / UA \
               /______\                               /______\
               SIP UA A                               SIP UA B

   Figure: Reference Model

   Here, the large rectangle 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, a proxy, and a redirector.  To the left we
   have two UA peers are behind network address translator.  On the
   right side, we have a P2PSIP Overlay "UA client", which uses the
   P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay.
   Below, we have conventional SIP UA "A", which has used SIP to
   interact with the Proxy Peer and establish a dialog with the UA peer,

There were three unnamed "UA peers" on the diagram. I'm not sure which one 
you were talking about, and I couldn't figure that out from the diagram (see 
previous whining about combining logical network topology and call paths on 
one diagram) but I at least named them in the diagram, so you can call one 
out in the text.

   and SIP UA "B" which has been redirected by the Redirect Peer and set
   up a dialog with the UA Client.  Note that the Proxy Peer and the UA
   Peer interact using the P2PSIP Overlay Peer Protocol, which is also
   presumably used on the keepalive links between the UA Peers and their

"keepalive links" hasn't been defined, and I'm not happy with the term. Are 
these any more than "logical links", in this context?

   neighbors.

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.

   After enrollment, each time the peer connects to the overlay, it must
   insert itself.  We don't have a defined protocol and process for
   this, and assume we need one.  Presumably the inserting peer connects

I agree that we need one.

   to one or more existing peers (possibly with the aid of a bootstrap
   server) presents its credentials, and ends up connected to the
   overlay, with some knowledge of neighbors (successor, precursor,
   finger tables, or whatever the distribution mechanism defines) and is
   able to store data on behalf of and route requests to other nodes in
   the P2PSIP overlay.

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

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

   Some peers and some clients may be coupled to SIP user agents, making
   them P2PSIP Overlay User Agents capable of both sending and receiving
   conventional SIP messages (as per a SIP UA) using conventional SIP
   resolution procedures and of using the resolution facilities provided
   by the overlay

(missing period after this sentence)

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?

3.3.4.  Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP
        Overlay Client UA

   Assume we have two users, Alice and Bob, who have successfully
   enrolled and inserted themselves into a P2PSIP Overlay using clients.
   Alice wants to call Bob, and enters Bob's user identity (AOR) into
   her client.  Alice's client does not have current knowledge of a
   route-set to Bob's client(s), so it needs to discover one.  Alice's

I was confused here. This text doesn't point anywhere for "it needs to 
discover one", so the reader is left to assume that "Alice's Client then 
does a GET operation on Bob's identity" is how that discovery happens, but 
"then does a GET" sounds like it happens AFTER discovering a route-set. If 
this is how discovery happens, please remove "then", and maybe even go to 
"it needs to discover one by doing a GET operation on Bob's identity".

   Client then does a GET operation on Bob's identity, using a
   previously-discovered peer, or using whatever procedures are needed
   (such as RFC 3263, a bootstrap server, etc.) to find a peer.  Alice's
   client send the GET request to the selected peer.

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?

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

   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.

4.  Questions

4.4.  Universal Routing:

   Do all P2PSIP Overlay Peers route requests?  How about clients?

I thought this was one of the differences between peers and clients. If it's 
not, what's the difference?

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

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.

4.15.  Overlapping Domains

   If the P2PSIP Overlay User Identifier is not scoped to a single DNS
   domain, this would appear to allow nodes from two or more apparent
   domains to share a single P2PSIP Overlay.  What, if anything, do we
   need to say about this mode of operation?

If a peer can locate an appropriate overlay AND provide appropriate 
credentials, what would prevent us from supporting this?

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?

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

I can imagine admissions control for enrollment, but I'm having a hard time 
imagining per-call admissions control in a decentralized P2P overlay - or 
was this the point of the question?

---

From: softgear at dcn.ssu.ac.kr (Softgear Ko)
Date: Wed, 20 Sep 2006 15:56:05 +0900

Hello.

In Reference Model Figure,  "Client Protocol" is connected to "Peer
Protocol" directly. I don't think it makes sense. We have to insert the node
which can connect to two protocols. It can be "Peer". 
I think, original figure's lines around P2PSIP overlay stand for kind of
network cloud -not connection.

Seokkap Ko.

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Spencer Dawkins
Sent: Friday, September 08, 2006 4:58 AM
To: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

Thanks,

Spencer Dawkins

High-level comments ...

of the choices?

Detailed comments ...

2.  Definitions

s/SU/Us/

3.  Discussion

3.2.  Reference Model

                                            --->PSTN
                                -----------/
    --------        |N|        | Gateway |

   Figure: Reference Model

   neighbors.

3.3.5.  Bootstrapping

4.  Questions

4.4.  Universal Routing:

4.9.  Cryptotransparency

4.13.  Bootstrapping

4.16.  Hybrid Domains

4.17.  Admissions Control

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

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 09:49:59 -0500

> network cloud -not connection.

Hmm. I'm not reading the figure that way, but the fact that you are  
concerns me. I'm becoming less and less fond of this drawing as time  
progresses.

Anybody have a better idea they can render in ASCII art?

--
Dean

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 20 Sep 2006 09:56:38 -0500

> Anybody have a better idea they can render in ASCII art?

Hi, Dean,

Have you gotten a chance to look at my revision?

>From the first note in this thread...

                                            --->PSTN
                                -----------/
    --------        |N|        | Gateway |

   Figure: Reference Model

My comments on the original version were

Any thoughts?

Thanks,

Spencer

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 16:20:09 -0500

> confusing. It is OK to have a short form, but can we deprecate at  

The intent was to list the "also known as" terms here. Perhaps  we  
need to distinguish between aka terms and "the official, in the  
context of P2PSIP, short form"?

> a "P2PSIP Overlay Key", compared to an "overlay key"?

Yes. A P2PSIP Overlay Key is unique to P2PSIP. Other overlay  
mechanisms might also use keys, but they might be of a different  
format, size, or intent. Or maybe I don't understand the question.

> below), assuming that they ARE part of the overlay.

No doubt. They're meant to be part of the overlay.

> don't like the result. If people agree, I can do ASCII art for (a)  

That might work.

> UA-peer or a UA-client). If you guys understand this perfectly,  

Peers are supersets of clients. Everything a client can do, a peer  
can do.

>       Overlay.  A P2PSIP Overlay SUer Agent differs from a  

yeah, that's a typo.

> Is this a "SIP INVITE", or something else? looks like a cut and  

Probably.

> Note - this is my redrawn picture, with changes on the left...

mostly.

> these any more than "logical links", in this context?

I think the term might have come from "outbound", but the idea is  
that there's a STUN keepalive usage there.

> I think this is required for the ad hoc scenarios, isn't it?

Can't have an overlay without peers.

But we don't have to do a full systems specification here. Somebody  
doing a full ad-hoc systems spec would have to solve enrollment.

But the idea was to leave the "do we need one" question to the WG,  
post-chartering.

> I agree that we need one.

Yep. This is a fundamental part of the "P2PSIP Overlay Peer Protocol".
> "expressivity" is a great word. Is it defined anywhere? ;-)

http://www.merriam-webster.com/dictionary/expressivity+

I've been doing a lot of genetics work lately relative to  
experimental oncology, and I'm afraid it's flavoring my vocabulary.

> (missing period after this sentence)

yep.

> "it needs to discover one by doing a GET operation on Bob's identity".

ok, maybe some rewriting needed.

> actually discovering something like a "P2PSIP Overlay Server"?

nope. It's discovering a P2PSIP Overlay Peer.

> not, what's the difference?

Nope. Some peers might possibly return a redirection instead of  
routing the request.

> I believe the answer to both of these is "yes" to support anything  

not unreasonable.

> credentials, what would prevent us from supporting this?

One would have to define search-ordering in the transdomain case.

> conventional SIP and P2PSIP overlays or not. Did we converge?

nope.

> was this the point of the question?

Both, really. Clearly we need some sort of enrollment and insertion  
control. Do we need a per-call admissions control? What might one  
look like if it were to exist? My personal belief is that this is an  
interesting question, but out of scope for now.

--
Dean

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 21 Sep 2006 12:41:26 -0500

Hi, Dean,

I think we're good on many of the things I listed earlier - just to follow 
up on a couple of questions...

(inline)

Spencer

> The intent was to list the "also known as" terms here. Perhaps  we  need 
> to distinguish between aka terms and "the official, in the  context of 
> P2PSIP, short form"?

That would be helpful for me.

> Yes. A P2PSIP Overlay Key is unique to P2PSIP. Other overlay  mechanisms 
> might also use keys, but they might be of a different  format, size, or 
> intent. Or maybe I don't understand the question.

Well, I didn't ask the question very clearly. What I was trying to ask was, 
would the overlay operate differently for a P2PSIP Overlay key than it would 
for any other overlay key. I understand that the P2PSIP Overlay key has a 
specific format/size/intent, I'm asking if the definition is true for 
generic DHT operation.

>> don't like the result. If people agree, I can do ASCII art for (a)  and 

I'll send this along soon.

> Peers are supersets of clients. Everything a client can do, a peer  can 
> do.

It would be good to include this text in the next draft of the document. It 
helped enormously.

>> well-understood usage. "Overlay bootstrap server" as short form?

<Did not see a note on the "bootstrap server" comment>

> I think the term might have come from "outbound", but the idea is  that 
> there's a STUN keepalive usage there.

OK. It would be good to spell this out a bit (since the term "keepalive 
link" does not appear in "outbound"). Is this text intended to require STUN?

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

> Nope. Some peers might possibly return a redirection instead of  routing 
> the request.

Again, this response was enormously helpful, and I'd like to see mention of 
redirection in the revised draft, but I asked my question too badly for you 
to actually grok it. What I was trying to say was, "I thought clients never 
routed requests OR returned redirections". If we're talking about a client 
receiving requests from the P2PSIP overlay that still need to be routed or 
redirected, some peer(/overlay server, but ignoring this for now) sent a 
request to the wrong place - or am I still face down in the snow?

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 27 Sep 2006 14:57:43 -0500

Hi, Dean,

Just following up on some ascii artwork, and some questions...

Thanks,

Spencer

>> don't like the result. If people agree, I can do ASCII art for (a)  and

I ended up with three pictures - one with a reference architecture, one with
a SIP routed INCITE, and one with a SIP redirected INVITE.

I also did some cleanup with box corners and using "#" to delimit the P2PSIP
Overlay, and labeled all the boxes unambiguously.

Please let me know how to improve this. If it's worth including in the
draft, I'll write some descriptive text, starting with what's in the draft
now.

                                             --->PSTN
                               +---------+  /
    +------+        |N|        | Gateway |-/
    |      |########|A|########|   Peer  |##############
    |  UA  |        |T|        |    G    |             # Client Protocol
    | Peer |                   +---------+             #  GET/PUT
    |  C   |                                           #   |
    +------+                                           #   |   \__/
       #                                               #   v   /  \
     |NAT|                                             #======/ UA \
       #                      P2PSIP Overlay           #     /Client\
       #                                               #     |___C__|
       #                        Route Data             #
    +------+      +------+                             #
    |      | |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

What I was trying to show in this figure was that the UA Client C is aware
of the P2PSIP overlay, while the SIP UAs A and B are not.

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           #     /Client\
       #                                               #     |___C__|
       #                        Route Data             #
    +------+      +------+                             #
    |      | |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
Server.

                                             --->PSTN
                               +---------+  /
    +------+        |N|        | Gateway |-/
    |      |########|A|########|   Peer  |##############
    |  UA  |        |T|        |         |             # Client Protocol
    | Peer |                   +---------+             #  GET/PUT
    |  C   |                                           #   |
    +------+                                           #   |   \__/
       #                                               #   v   /  \
     |NAT|                                             #======/ UA \
       #                      P2PSIP Overlay           #     /Client\
       #                                               #     |______|
       #                        Route Data             #        ^
    +------+      +------+                             #        |
    |      | |N|  |      |                             #        |
    |  UA  |#|A|##|  UA  |                             #        |
    | Peer | |T|  | Peer |                             #        |
    |  D   |      |  E   |                             #        |
    +------+      +------+                             #   SIP  |
        Peer Protocol #   +-------+        +-------+   #  INVITE/200 OK
                      #   |       |        |       |   #        |
                      ####| Proxy |########| Redir |####        |
                          | Peer  |        | Peer  |            |
                          |       |        |       |            |
                          +-------+        +-------+            |
                                                   \            |
                                    SIP             \          /
                 \__/               INVITE/302 Moved \  \__/  /
                  /\                                  \  /\  /
                 /  \                                  \/  \/
                / UA \                                 / UA \
               /______\                               /______\
               SIP UA A                               SIP UA B

   Figure: Redirect from P2PSIP Overlay

A little further into our discussion of the draft...

> Peers are supersets of clients. Everything a client can do, a peer  can

I really like this sentence - if others agree, I'd like to see it in the
draft.

I did have one question - the Client GET/PUT protocol will be unicast to a
specific P2PSIP overlay peer, won't it? How should the Client choose a
specific overlay peer?

Thanks,

Spencer

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 27 Sep 2006 16:21:51 -0400

Hi, Spencer,

All the three diagrams look good.
My comments are inline.

> draft, I'll write some descriptive text, starting with what's in the draft

A Client node should send its GET/PUT requests to a Peer (or Peers). In
other words, the Client Protocol is spoken between a Client and a Peer.
In that sense, I guess it would be better if the line from UA Client C
is connected to one of Peers. What do you think?

> UA A to UA Peer E, through Proxy Peer C.
I agree.

> specific P2PSIP overlay peer, won't it? 
I think so.

How should the Client choose a
> specific overlay peer?

A Client can get information about some existing Peers from P2PSIP
Overlay Bootstrap Server. The Client can keep the information and send
the PUT/GET request to those Peers.

Over the time, the Client may be able to find other Peers. We should
make sure there is a mechanism for that. Otherwise, many Clients may be
stuck with the same set of Peers that are known to the Bootstrap Server.
One possible solution is to assign a Node ID to the Client as well and
let the Client talk to the Peer whose Node ID is closest to the Client's
Node ID. It works because the Client should be able to find a Peer whose
Node ID is closest to the Client's Node ID from DHT.

Thanks.

Eunsoo

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 27 Sep 2006 16:55:41 -0400

Comments inline.

> is connected to one of Peers. What do you think?

Agree

> > I really like this sentence - if others agree, I'd like to see it in the

One caveat to be a bit closer. The statement "all P2PSIP overlay peers
are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
peers are SIP UA clients" may not be. There could be adaptor nodes, as
described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
overlay peers, but would have no SIP endpoint functionality -- they
would only serve to adapt traditional SIP UA clients that are not
P2PSIP overlay client protocol aware so they can communicate with the
network.

> I think so.

I think so too.

> Node ID is closest to the Client's Node ID from DHT.

Could be many mechanisms here. Configuration of known persistent peer,
broadcast to find peer, etc. 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. In my draft, the bootstrap peer basically does a first
level lookup and always offloads, keeping the load light on any peer
that might be serving as a bootstrap.

David

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 27 Sep 2006 14:33:41 -0700

David's comment should be included IMHO in future architecture
documents:

" 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. In my draft, the
bootstrap peer basically does a first level lookup and always offloads,
keeping the load light on any peer that might be serving as a
bootstrap."

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, September 27, 2006 1:56 PM
To: Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

Comments inline.

On 9/27/06, Eunsoo Shim <eunsoo at research.panasonic.com> wrote:
> >>> - Figure 1 seems confused on whether the UA/Peers behind the NATs
are
> >>> part
> >>> - Figure 1 is also trying to do more than you can do in ASCII art
(at
> >>> least
> >>> I think so) - the dotted lines either mean (a) logical
connectivity  in
> >>> the
> >>> overlay, (b) physical connectivity through the NATs, or (c) a SIP
call.
> >>> I
> >>> doubled the lines for the overlay topology, but left the SIP calls
in
> >>> and
> >>> don't like the result. If people agree, I can do ASCII art for (a)
and
> >>> (c),
|___C__|

Agree

> > UA A to UA Peer E, through Proxy Peer C.
|___C__|
> >        #                        Route Data             #
|______|
> >>> - I'm very confused about how both clients and peers can be
"endpoints".
> >>> For
> >>> 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
can

I think so too.

David

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 27 Sep 2006 16:34:16 -0500

Thanks, both Eunsoo and David, for quick feedback.

>> is connected to one of Peers. What do you think?

Cool. Should I just show the Peer as "Peer F", or is there a better term? I 
think I'm asking if I should include David's term "adaptor node" in the 
diagram.

> P2PSIP overlay client protocol aware so they can communicate with the

Thanks for this clarification. It also helps.

> that might be serving as a bootstrap.

Again, thanks for the clarification.

Spencer

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 27 Sep 2006 18:45:43 -0400

I don't believe that adaptor node made it into the terminology draft,
but I'm fine with using it as a label if others are comfortable. (it
just never happened to come up in that discussion).

David

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 27 Sep 2006 16:09:54 -0700

Ooops!

What I meant to say: What are the alternative options for load balancing
to avoid overloaded peers?

Sorry, I did not mean to support SIP as a peer client protocol. This
choice has yet to be made after we look at the requirements, options,
etc.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Henry Sinnreich
Sent: Wednesday, September 27, 2006 2:34 PM
To: David A. Bryan; Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu; Kundan Singh
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01

Thanks, Henry

-----Original Message-----

Comments inline.

are
(at
connectivity  in
call.
in
and
|___C__|

Agree

|___C__|
|______|
"endpoints".
(either
please
can

I think so too.

David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 27 Sep 2006 23:55:48 -0400

Doesn't the Proxy Peer do a similar function?
We have Proxy Peer in the diagram(s).
Thanks.

Eunsoo

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 28 Sep 2006 07:41:06 -0500

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

Thanks,

Spencer

---

From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 28 Sep 2006 09:17:03 -0400

I was thinking that an adaptor might be an entity that had more than
just proxy -- we also specify a registrar in that same section. For a
true C/S node to work, it would need to be able to do lookups and
registration.

We need to make some clarifications to the terminology draft.

David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 28 Sep 2006 10:25:01 -0400

>From the SIP perspective, Proxy does the same thing about SIP message
routing regardless of whether it uses the P2PSIP Overlay to resolve the
 IP address of the next hop or uses the DNS. The next hope could be
another proxy or the destination.
Proxy Peer is nothing but a SIP Proxy that is a Peer and thus can use
the P2PSIP Overlay to find the location of the destination (or the next
hop).
As written in the terminology and concepts draft, there can be a Proxy
Client.

Therefore, Proxy Peer and Proxy Client can always interact with CS-SIP
in my understanding.

Thanks.

Eunsoo

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 28 Sep 2006 10:38:13 -0400

One can put the Proxy functionality and Registrar functionality into a
single entity.
They can be separate, too.
Figure 3 and 4 in draft-shim-sipping-p2p-arch-00.txt show how Registrar
Peer/Client and Proxy Peer/Client can enable interoperation between a UA
Peer/Client and CS SIP UAs.
According to the terminology style of draft-willis-p2psip-concepts-01,
P2P Proxy in the first draft is Proxy Peer/Client and P2P Registrar is
Registrar Peer/Client.

Thanks.

Eunsoo