Subject: [p2p-sip] Draft charter for possible P2PSIP WG

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 17 Jan 2006 00:30:19 -0500

A number of us (myself, Dean Willis, Eunsoo Shim, Henry Sinnreich,
Cullen Jennings, Philip Matthews, Henning Schulzrinne, and others I am
sure I have forgotten) have been bouncing around a few ideas for a
proposed draft charter for a WG to address some of the problems we
have been discussing on the mailing list. We pulled things into a
document and wanted to post it to the mailing list to get feedback.
Please take a look and comment. (inline and attached)

--David Bryan

-----

Note: This working group is likely to be moved to the RAI, rather than
Transport as soon as such a group exists. We'll list Transport for now
as place holder text

Peer-to-Peer Session Initiation Protocol (P2PSIP)
DRAFT 2006/01/16

Chairs:
TBD

Transport Area Director(s):
Allison Mankin <mankin at psg.com>
Jon Peterson <jon.peterson at neustar.biz>

Transport Area Advisor:
TBD

Mailing Lists:
General Discussion: p2p-sip at cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/

Description of the Working Group

The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol
working group (P2PSIP WG) is to develop guidelines and mechanisms for
the use of the Session Initiation Protocol (SIP) in settings where
establishing and managing sessions is either partially or entirely
handled by a collection of endpoints (peers) rather than centralized
servers. This is an alternative to the conventional SIP approach of
using a hierarchy of proxies where the mapping of users to proxies is
determined by a combination of out-of-band and geographic mechanisms.

This is motivated by scenarios where a reduction in cost of equipment
and operation for non-end users is desired, and in situations where
such servers are not available. Some of the scenarios identified
include:

1. Self-organizing and highly available proxy farms, as opposed to the
   fixed hierarchy of IMS-like systems.
2. Disconnected or partly-connected topologies with ephemeral
   relationships such as small office systems (with little or no
   central equipment), mesh networks, emergency response, and
   battlelfield environments.
3. Recovery functions to allow endpoints to communicate in the event a
   central server fails or the endpoints are isolated by a network
   partitioning event.

The working group starts with the following general assumptions:

1. Peer associations groups, which may be called "P2P networks". 'P2P
   overlays", or "P2P federations" will provide namespaces within
   which P2P-SIP resources are identified. These namespaces are
   bounded by the identifier(s) of the peer association group, which
   generally map to domain-level identifiers in the DNS.
2. Session establishment, capabilities negotiation, session
   termination, subscription, notification, messaging, and related
   functions traditionally performed using SIP will continue to be
   performed using SIP. This working group is interested only in the
   mechanisms for locating resources within peer association
   groups. We generally refer to this as the "rendezvous problem".
3. Some elements of each peer association group MAY be rooted in the
   DNS such that they can be used for bootstrapping operations.
   However, a peer association group that is operating entirely in an
   isolated (or disconnected, or autonomous) mode will rely on
   alternate means of bootstrapping the peer association group based
   on the "zeroconf" work.
4. Interactions between peer association groups (or members thereof)
   and other peer association groups or conventional SIP installations
   will be resolved using the resource location model of RFC 3262:
   "Locating SIP Servers".
5. The level of authenticity of identity will vary by the peer
   association group. However, the working group will define at least
   one mechanism that will provide assertion of identity having
   strength equivalent to that provided by the "SIP Identity
   Mechanism" RFC, perhaps by reusing some or all of the mechanism of
   that RFC.

Specifically, the working group will:

1. Document scenarios in which a P2P architecture is appropriate for
   SIP based solutions ("use-cases" document).
2. Develop a general architecture or framework for P2P-based SIP
   applications. This will require evaluating the existing deployed
   and proposed P2P-based SIP solutions for possible incorporation
   into this work.
3. Define a distributed location mechanism for locating users in the
   absence of a central server, including the protocols and algorithms
   needed do establish, maintain, and query the distributed
   information.
4. If SIP extensions are needed to support the peer-to-peer model,
   define requirements for those extensions to be acted on by the SIP
   working group.

While ensuring:

1. Security is addressed in these systems.
2. Interoperability with existing client-server (CS) SIP and the PSTN.
3. The solutions proposed will function even with many nodes located
   behind NATs or firewalls.
4. Existing protocols are reused whenever possible.

The following topics are initially out of the Working Group's scope,
but may be considered in possible future charters:

1. Using P2P mechanisms to manage groups of distributed media relays.
2. Using distributed relays to enable anonymous communications.
3. Creating distributed voice mail systems.
4. Performing distributed search for users based on something other
   than user id.

The following topics are explicitly excluded from the Working Group's
scope:

1. Issues specific to applications other than locating users and
   resources for SIP-based communications.
2. Discussion of this technology as a replacement for SIP.
3. Solving "research" type open questions related to P2P SIP. The
   working group will instead forward such work to the IRTF. A few
   such topics include:
   o Fully distributed schemes for assuring unique user identities.
   o Development of new structured P2P algorithms, such as DHTs.
   o Developing a P2P-based replacements for DNS.

The working group will operate in close cooperation with the SIP,
SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
IRTF. Respecting the IETF specification change policy, the working
group will refer any possible changes or extensions as suggestions to
the appropriate WGs as needed. A guiding principal of the WG will be
to avoid extensions or change wherever possible.

Goals and Milestones
Aug 2006	Submit use-cases document to the IESG (Informational)
Jan 2007	Submit architecture document to the IESG (Informational)
Jul 2007	Submit protocol and/or protocol extension documents to
                the IESG (Standards-track)
-------------- next part --------------
Note: This working group is likely to be moved to the RAI, rather than
Transport as soon as such a group exists. We'll list Transport for now
as place holder text 

Peer-to-Peer Session Initiation Protocol (P2PSIP)
DRAFT 2006/01/16

Chairs:
TBD

Transport Area Director(s):
Allison Mankin <mankin at psg.com> 
Jon Peterson <jon.peterson at neustar.biz>

Transport Area Advisor:
TBD

Mailing Lists:
General Discussion: p2p-sip at cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/

Description of the Working Group

The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol
working group (P2PSIP WG) is to develop guidelines and mechanisms for
the use of the Session Initiation Protocol (SIP) in settings where
establishing and managing sessions is either partially or entirely
handled by a collection of endpoints (peers) rather than centralized
servers. This is an alternative to the conventional SIP approach of
using a hierarchy of proxies where the mapping of users to proxies is
determined by a combination of out-of-band and geographic mechanisms.

This is motivated by scenarios where a reduction in cost of equipment
and operation for non-end users is desired, and in situations where
such servers are not available. Some of the scenarios identified
include:

1. Self-organizing and highly available proxy farms, as opposed to the
   fixed hierarchy of IMS-like systems.
2. Disconnected or partly-connected topologies with ephemeral
   relationships such as small office systems (with little or no
   central equipment), mesh networks, emergency response, and
   battlelfield environments. 
3. Recovery functions to allow endpoints to communicate in the event a
   central server fails or the endpoints are isolated by a network
   partitioning event. 

The working group starts with the following general assumptions:

1. Peer associations groups, which may be called "P2P networks". 'P2P
   overlays", or "P2P federations" will provide namespaces within
   which P2P-SIP resources are identified. These namespaces are
   bounded by the identifier(s) of the peer association group, which
   generally map to domain-level identifiers in the DNS. 
2. Session establishment, capabilities negotiation, session
   termination, subscription, notification, messaging, and related
   functions traditionally performed using SIP will continue to be
   performed using SIP. This working group is interested only in the
   mechanisms for locating resources within peer association
   groups. We generally refer to this as the "rendezvous problem". 
3. Some elements of each peer association group MAY be rooted in the
   DNS such that they can be used for bootstrapping operations. 
   However, a peer association group that is operating entirely in an
   isolated (or disconnected, or autonomous) mode will rely on
   alternate means of bootstrapping the peer association group based
   on the "zeroconf" work.  
4. Interactions between peer association groups (or members thereof)
   and other peer association groups or conventional SIP installations
   will be resolved using the resource location model of RFC 3262:
   "Locating SIP Servers". 
5. The level of authenticity of identity will vary by the peer
   association group. However, the working group will define at least
   one mechanism that will provide assertion of identity having
   strength equivalent to that provided by the "SIP Identity
   Mechanism" RFC, perhaps by reusing some or all of the mechanism of
   that RFC. 

Specifically, the working group will:

1. Document scenarios in which a P2P architecture is appropriate for
   SIP based solutions ("use-cases" document). 
2. Develop a general architecture or framework for P2P-based SIP
   applications. This will require evaluating the existing deployed
   and proposed P2P-based SIP solutions for possible incorporation
   into this work. 
3. Define a distributed location mechanism for locating users in the
   absence of a central server, including the protocols and algorithms
   needed do establish, maintain, and query the distributed
   information. 
4. If SIP extensions are needed to support the peer-to-peer model,
   define requirements for those extensions to be acted on by the SIP
   working group. 

While ensuring: 

1. Security is addressed in these systems. 
2. Interoperability with existing client-server (CS) SIP and the PSTN.
3. The solutions proposed will function even with many nodes located
   behind NATs or firewalls.  
4. Existing protocols are reused whenever possible.

The following topics are initially out of the Working Group's scope,
but may be considered in possible future charters:

1. Using P2P mechanisms to manage groups of distributed media relays.
2. Using distributed relays to enable anonymous communications.
3. Creating distributed voice mail systems.
4. Performing distributed search for users based on something other
   than user id. 

The following topics are explicitly excluded from the Working Group's
scope: 

1. Issues specific to applications other than locating users and
   resources for SIP-based communications. 
2. Discussion of this technology as a replacement for SIP.
3. Solving "research" type open questions related to P2P SIP. The
   working group will instead forward such work to the IRTF. A few
   such topics include:  
   o Fully distributed schemes for assuring unique user identities.
   o Development of new structured P2P algorithms, such as DHTs.
   o Developing a P2P-based replacements for DNS.

The working group will operate in close cooperation with the SIP,
SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
IRTF. Respecting the IETF specification change policy, the working
group will refer any possible changes or extensions as suggestions to
the appropriate WGs as needed. A guiding principal of the WG will be
to avoid extensions or change wherever possible. 

Goals and Milestones
Aug 2006	Submit use-cases document to the IESG (Informational)
Jan 2007	Submit architecture document to the IESG (Informational)
Jul 2007	Submit protocol and/or protocol extension documents to
                the IESG (Standards-track)

---

From: kns10 at cs.columbia.edu (Kundan Singh)
Date: Tue, 17 Jan 2006 08:41:08 -0500

Minor suggestions/corrections below --

>    will be resolved using the resource location model of RFC 3262:

RFC 3262 => RFC 3263

>    behind NATs or firewalls.

Should this be "some nodes" instead of "many nodes"? Just so that we 
don't have to guarantee that it works efficiently if 99% nodes are 
behind NATs.

> 4. Performing distributed search for users based on something other

user id => SIP address-of-record, or namespace plus user id.
(unless userid is assumed as user at domain or namespace+userid)

> 2. Discussion of this technology as a replacement for SIP.

SIP => conventional SIP (or client-server)?

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 17 Jan 2006 09:33:16 -0500

On 17-Jan-06, at 8:41 , Kundan Singh wrote:
   [snip]

> don't have to guarantee that it works efficiently if 99% nodes are

I personally think it is important that whatever solution we come up  
with
work effectively if ALL the peers are located behind NATs.

In very large networks, especially networks composed of home and  
academic nodes,
it may be reasonable to assume that there will be peers that
are not behind a NAT.

However, in smaller networks and/or in enterprise settings, I believe  
that
assumption is not reasonable. On the contrary, I believe it will be  
normal
for EVERY peer to be located behind a NAT.

- Philip

---

From: enrico.marocco at TILAB.COM (Enrico Marocco)
Date: Tue, 17 Jan 2006 16:05:22 +0100

I like it very much, but it doesn't clarify one issue: how will the
group deal with presence?
I can imagine that we don't intend to specify a distributed presence
server, but what about regev? Does it fall under out of scope stuff?

Actually, the topic is treated in a couple of drafts, but it's never
been deepened.

Enrico

> Please take a look and comment. (inline and attached)

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
MailAdmin at tilab.com. Thank you
====================================================================

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 18 Jan 2006 13:37:47 -0500

> -----Original Message-----
> From: Philip Matthews
> Sent: Tuesday, January 17, 2006 9:33 AM
> Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG
> 

In an enterprise setting it's likely all nodes will be behind the *same*
NAT, but unlikely they'll be behind different NATs.

Indeed, I think it unlikely there will *ever* be a deployment where each and
every node is behind its own unique NAT.

Regardless, so long as there is *some* connectivity path between all nodes
(ie, A->B->C->D) I guess it'd be possible to forward NAT traversal requests
just like INVITE requests are forward in SIP (and another reason why to
build the NAT traversal algorithm into the SIP protocol itself).

And if two nodes have *no* connectivity path, you could use a Roti-like
port-scanning technique (which requires no rendezvous service).

But all this sounds like a pretty extreme boundary case.  While there are
certainly people working on isolated networks, I really doubt they'll be
using NATs too.  I'd offer P2P-SIP should work:

1) On the internet where some global bootstrapping service is available, and
some or all non-bootstrapping nodes are behind NATs.

2) Off the internet where UDP broadcasts work, no nodes are behind NATs, and
no bootstrapping service is available.

-david

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 18 Jan 2006 13:48:04 -0600

>>    will be resolved using the resource location model of RFC 3262:

Good catch. I typoed.

> don't have to guarantee that it works efficiently if 99% nodes are

Makes no difference to me.

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

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Wed, 25 Jan 2006 23:49:37 +0200

A few comments on the draft charter text.

> determined by a combination of out-of-band and geographic mechanisms.

The last sentence is a bit too sophisticated to efficiently communicate 
the message. How about simply saying that the conventional SIP approach 
relies on service provider hosted proxies to which users get assigned by 
out-of-band means, usually based on geography, association or business 
reasons.

>    generally map to domain-level identifiers in the DNS.

I find this a little hard to understand. I guess the meaning is to still 
use a username at domain construct for user ids, and that each domain's 
name is rooted in the DNS? If so, why not just say that?

>    alternate means of bootstrapping the peer association group based

This isn't either or; perhaps it could also be mentioned that peers can 
very well sometimes be in disconnected mode, while other times in 
connected mode. In such cases, the names should have global scope in 
both modes.

Maybe say that names should always have global scope?

>    and proposed P2P-based SIP solutions for possible incorporation

I've come to dislike "architecture" or "framework" documents, but if 
they must be done, they must be done...

> 2. Interoperability with existing client-server (CS) SIP and the PSTN.

Mentioning the PSTN makes me uneasy, isn't "traditional" SIP enough 
here? Sounds like a draft about ISUP to P2PSIP mapping is otherwise sure 
follow ;)

> 1. Using P2P mechanisms to manage groups of distributed media relays.

Hmm.. I understand this in terms of the charter being scoped to SIP only 
(initially), but this seems like cutting out a major part of where 
distributing or sharing resources actually is a big benefit.

After all, running a SIP proxy is quite cheap; disk and cpu are cheap 
and SIP doesn't consume that much bandwidth. Running a TURN server then 
again is another thing entirely. I can't see a system that has 
distributed rendezvous having to resort to centralized media relays.

Shouldn't this rather be included in the first iteration already?

>    resources for SIP-based communications.

See my previous point.

Otherwise sounds good.

Cheers,
Aki

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 26 Jan 2006 15:10:58 -0500

Aki:

Thanks very much for your specific comments on the proposed charter  
text.
As one of those who worked on the draft text, having specific  
comments like this
is very helpful.

See comments inline.

- Philip

> out-of-band means, usually based on geography, association or business

If I understand your proposal, then you are suggesting that the last  
sentence be replaced with
               "This is an alternative to the conventional SIP  
approach of
relying of service provider hosted proxies to which users get  
assigned by
out-of-band means, usually based on geography, association or  
business reasons."

I don't personally object to the proposed rewording, though I am not  
sure this is really better.

> Maybe say that names should always have global scope?

I would personally be reluctant to say in the charter that names must  
always have global
scope until I better understood the implications of that statement.  
Currently,
I suspect that having user and resource names which are unique only  
within
a specific P2P-SIP network are much more realistic.

> they must be done, they must be done...

In this case, I think that it is essential that the working group  
work on
such document(s). However, it may be that we do not need to publish
them as RFCs. (Personally, I think it would be good to have them as  
RFCs,
but I can see the arguments for not doing so).

> here? Sounds like a draft about ISUP to P2PSIP mapping is otherwise  

This is a good point.

I would be happy if moved PSTN interoperability to the "after a  
possible rechartering" section.

> Shouldn't this rather be included in the first iteration already?

I believe that we really need to have a small set of deliverables for  
the initial charter,
otherwise the charter won't get past the IESG. In my opinion, only  
really essential stuff
should be part of the first set of deliverables. So, for example, I  
am personally very interested
in item 3 below (voicemail), but I am not objecting to leaving it for  
after a re-charter
because I don't consider it "essential".

In my opinion, item 1 (distributed media relays) are also not  
essential and
should wait until after a re-charter.

Does this make sense? Do you agree?

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Fri, 27 Jan 2006 00:12:10 +0200

Inline.

ext Philip Matthews wrote:
>               "This is an alternative to the conventional SIP approach of
> relying of service provider hosted proxies to which users get assigned by

s/of/on

> reasons."

Yes.

> sure this is really better.

Well, I think it is clearer this way.

> I suspect that having user and resource names which are unique only within

My point is that nodes can move around and be part of both disconnected 
and connected overlays. It probably makes sense for that node to use the 
same name in each scenario, and that name to not collide with other names.

> should be part of the first set of deliverables. So, for example, I am 
> personally very interested
> In my opinion, item 1 (distributed media relays) are also not essential and

Voicemail is hardly an essential feature. But media relays are needed to 
get around the most difficult middleboxes. What fraction of nodes are we 
expecting to live behind such boxes, and by not counting those in does 
it represent a complete enough solution?

Because I just can't see a P2PSIP that requires centralized media relays 
to work properly getting off the ground (any better than traditional SIP).

Cheers,
Aki

---

From: henry at pulver.com (Henry Sinnreich)
Date: Fri, 27 Jan 2006 08:49:07 -0600

Folks,

As mentioned, please focus on _short_ contributions to the charter text.
Unless we make it to the BOF and WG, all of this here addressed to the whole
list is turning into an unexpected P2P SIP result: Email SPAM.

Most respectfully, your Henry