[p2p-sip] My notes on draft-willis-p2psip-concepts-01
softgear at dcn.ssu.ac.kr
Wed Sep 20 02:56:05 EDT 2006
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.
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
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.
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
- 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
Detailed comments ...
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
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
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.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
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...
-------- |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?
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
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.
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
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
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?
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
I believe this question is key when we discuss what an endpoint is (see
previous comments on whether clients are endpoints).
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
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
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?
p2p-sip mailing list
p2p-sip at cs.columbia.edu
More information about the P2p-sip