Subject: [P2PSIP] Proposal for progress on protocols

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 6 Nov 2007 21:26:22 -0500

I'd like to propose a mechanism to make progress on converging on a  
protocol. My high-level impression is that most of the proposals, with  
the exception of the HIP-based ones, are philosophically not that far  
removed, and the differences are more at the mechanical level. One way  
to make progress would be to identify some of the major pieces, and  
then, in Vancouver, systematically go through them. An initial list,  
definitely incomplete, includes

- packet format
- NAT traversal for p2p messages (not media or SIP signaling)
- channel security for p2p messages
- recursion vs. iterative
- hash algorithm negotiation and usage

One possibility is to identify a volunteer for each area, so that the  
task is more manageable. If there are major philosophical differences,  
we should probably discuss those first, however.

Henning

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Nov 2007 06:05:08 -0800

Dear co-chairs,

Can we put this item on the P2PSIP WG meeting agenda?

Thanks,

Henry Sinnreich

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2007 8:26 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] Proposal for progress on protocols

- packet format

Henning

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 07 Nov 2007 08:40:32 -0600

Dear P2PSIP working group,

Can we also discuss these topics between now and the P2PSIP meeting in 
Vancouver, which is about a month away? :-)

We REALLY need more mailing list traffic on specific text between 
meetings...

I agree with Henning's proposal. I'm willing to volunteer for "recursion vs 
iterative".

Two related questions:

- do we know which drafts Henning's proposal covers? Only the non-HIP drafts 
prepared for IETF 69, or are there other drafts people have been working on 
since then? and

- are current versions of these drafts available, or are people working 
madly to submit something before the ID cutoff?

Thanks,

Spencer

----- Original Message ----- 
From: "Henry Sinnreich" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>; "P2PSIP Mailing List" 
<[email-masked]>
Sent: Wednesday, November 07, 2007 8:05 AM
Subject: RE: [P2PSIP] Proposal for progress on protocols

Dear co-chairs,

Thanks,

Henry Sinnreich

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, November 06, 2007 8:26 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] Proposal for progress on protocols

- packet format

Henning

---

From: Emil Ivov <[email-masked]>
Date: Wed, 07 Nov 2007 17:53:15 +0100

Henning, all,

I think this is definitely the way to go and both Enrico and I (as
authors of one of the proposals) would be happy to contribute on any of
the points in your list. We also thought that there are two other issues
that would probably require some consideration:

- DHT upgrades - as far as I can see, it is currently most covered by
ASP, but the general opinion in Chicago seemed to be that this is indeed
an important issue that would have to be addressed by the peer protocol.

- Mobility - taking mobility into account would probably influence some
of the design choices (underlying protocol, session flexibility, etc..)
so it might be worth to try and see to what extent would the existing
proposals fit mobile nodes.

One last thing. We should probably try and start having some of these
discussions before the meeting or, even better, to find some way to
foster offline work on each topic, since they are likely to require more
than the time we'll have there. I guess that Philip's presentation in
Chicago was made with the same intentions, but it was pretty clear that
the time we had was insufficient for any meaningful discussions.

Cheers
Emil

---

From: Ingmar Baumgart <[email-masked]>
Date: Wed, 07 Nov 2007 23:58:22 +0100

Dear working group,

to answer the second question: I'm one of these people working (more or
less madly ;-) ) on a proposal called "Peer-to-Peer Name Service (P2PNS)".

This proposal describes our P2PSIP implementation (based on OverSim)
which we presented at P2P2007 recently. The main contribution is on two
aspects: One is reusability of the name service for things like
distributed DNS or HIP. The other is security in a completely
decentralized environment (without login severs).

It would be great if these aspects could also be included in the
discussion (The draft should be finished on Friday...).

Regards,
  Ingmar

Spencer Dawkins wrote:
> I agree with Henning's proposal. I'm willing to volunteer for "recursion
> vs iterative".
> 
> Two related questions:
> 
> - do we know which drafts Henning's proposal covers? Only the non-HIP
> drafts prepared for IETF 69, or are there other drafts people have been
> working on since then? and
> 
> ----- Original Message ----- From: "Henry Sinnreich" <[email-masked]>

--
Dipl.-Inform. Ingmar Baumgart
Institut für Telematik, Universität Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone: +49 721 608 8281, Fax: +49 721 608 6789

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Nov 2007 17:30:09 -0800

Spencer,

>- do we know which drafts Henning's proposal covers?

P2PP has running code and is available online. 
I expect P2PP-01 to be out shortly.

For all the existing proposals, please consider also the I-D by Brian
Carpenter "Considering availability of free software when evaluating
Draft Standards"
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-carpenter-ipr-pa
tent-frswds-01.txt 

      A specification from which at least two independent and
interoperable
      implementations from different code bases have been developed, _of
      which at least one is preferably available as free software_, and
      for which sufficient successful operational experience has been
      obtained, may be elevated to the "Draft Standard" level.

(my underline)

Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 8:41 AM
To: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

vs 
iterative".

Two related questions:

- do we know which drafts Henning's proposal covers? Only the non-HIP
drafts 
prepared for IETF 69, or are there other drafts people have been working
on 
since then? and

Thanks,

Spencer

----- Original Message ----- 
From: "Henry Sinnreich" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>; "P2PSIP Mailing List" 
<[email-masked]>

Dear co-chairs,

Thanks,

Henry Sinnreich

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, November 06, 2007 8:26 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] Proposal for progress on protocols

- packet format

Henning

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Nov 2007 17:46:21 -0800

>      obtained, may be elevated to the "Draft Standard" level.

Henry,
	That draft is an individual submission that's being discussed
in the IPR working group.  My current assessment is that there is no
consensus behind Brian's language, with multiple folks preferring the
language by Scott Brim:

>    interoperable implementations from different code bases have been
>    developed, and for which sufficient successful operational
>    experience has been obtained, may be elevated to the "Draft
>    Standard" level.  Issues with general deployability should be
>    taken into consideration, including issues of licensing terms
>    associated with those implementations.      

	The main issue being that what qualifies as "free software"
could turn out to be a rathole of epic proportions.  For those interested
in developing a consensus on this please join the IPR list and express
your opinions.  
	At this juncture, at least, this working group needs to get
out a PS.  We have at least six months after that to worry about DS :) .

			regards,
				Ted

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Nov 2007 18:22:22 -0800

>- DHT upgrades

Please help me understand why infrequent software upgrades have to be
part of the p2p overlay functions or its services, such as SIP.

Or maybe we are talking of different things?

Thanks, Henry

-----Original Message-----
From: Emil Ivov [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 10:53 AM
To: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

Henning, all,

Cheers
Emil

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Nov 2007 18:22:23 -0800

Ingmar, this is very interesting.

>which we presented at P2P2007 recently.

Is there a link to the existing document?

Thanks, Henry

-----Original Message-----
From: Ingmar Baumgart [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 4:58 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

Dear working group,

Regards,
  Ingmar

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 08 Nov 2007 09:26:22 +0100

> Or maybe we are talking of different things?

I guess Emil is referring to DHT migration as described in section 2.6
of ASP draft, not exactly to software upgrades.  The issue was raised by
Jonathan during the ad-hoc meeting in Chicago and, AFAIR, it was quite
agreed that it is something which should be considered from the very
beginning.  The main point was that, since overlays are supposed to last
for long periods, they may require upgrades and migrations which are
unlikely to happen if a common mechanism was not agreed in advance.

-- 
Ciao,
Enrico

---

From: <[email-masked]>
Date: Thu, 8 Nov 2007 11:28:48 +0200

Hi all,

I agree with Henning's proposal. There is another issue: support for
clients. 

I can to volunteer for "mobility" or "support for clients".   

Marcin 

>From: ext Emil Ivov [mailto:[email-masked]] 
>Sent: 07 November, 2007 18:53
>To: P2PSIP Mailing List
>I think this is definitely the way to go and both Enrico and I 
>(as authors of one of the proposals) would be happy to 
>contribute on any of the points in your list. We also thought 
>that there are two other issues that would probably require 
>some consideration:
>
>- DHT upgrades - as far as I can see, it is currently most 
>covered by ASP, but the general opinion in Chicago seemed to 
>be that this is indeed an important issue that would have to 
>be addressed by the peer protocol.
>
>- Mobility - taking mobility into account would probably 
>influence some of the design choices (underlying protocol, 
>session flexibility, etc..) so it might be worth to try and 
>see to what extent would the existing proposals fit mobile nodes.
>
>One last thing. We should probably try and start having some 
>of these discussions before the meeting or, even better, to 
>find some way to foster offline work on each topic, since they 
>are likely to require more than the time we'll have there. I 
>guess that Philip's presentation in Chicago was made with the 
>same intentions, but it was pretty clear that the time we had 
>was insufficient for any meaningful discussions.
>
>Cheers
>Emil
>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 08 Nov 2007 11:38:08 -0600

Backing up from Ted's reasonable points about Henry's reasonable high-level 
concerns ...

IPR discussions are going to be challenging enough (with or without Brian's 
draft, which doesn't change patent law) that as one of the volunteers, I 
would prefer to do the analysis, let people look at the analysis and pick a 
preferred direction, and then consider IPR concerns for that preferred 
direction.

If the preferred direction for one of these decision points is encumbered, 
we can figure out what to do then.

Spending time trying to understand what the IPR considerations for ideas 
that the working group will reject because of technical considerations 
doesn't sound like fun to me.

One minor point that Henry may be assuming - are all the people who have 
submitted proposals current on their IPR disclosures? I've seen delays of 
months in other groups between draft submission and IPR disclosure 
submission - we really need to know as much as we can know when we DO 
consider IPR concerns.

Thanks,

Spencer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 10 Nov 2007 10:53:58 -0500

I think Philips presentation and the slides he put together last time 
were meant to do exactly this kind of thing - to show in what ways 
various proposals were the same, and where they were different.

That said, what I do NOT want to do, is to try and work through each and 
every issue for a p2p protocol through a group consensus process, and 
then assemble the results into a built-from-ground-up working group 
document. I've seen that process tried before in other groups (midcom, 
the impp protocols), and in each case it has been a dismal failure, 
taking a long time and producing results no one liked.

I'd prefer to do what we normally do - adopt one of the drafts as a 
working group item and make changes from there based on discussions. 
Note that, just because a document is adopted as a working group item 
doesn't mean it can't be changed. But it does mean that the document is 
believed to be on the right track and a "good starting point" for 
producing the final deliverable.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 11 Nov 2007 15:35:09 -0800

Would a limited generic/broad set of requirements be a good start?

Something quite general, such as

- Must work on the Internet 'as is' today
- Most peers are presumed to be behind NAT
- etc.

No routing or protocol specifics of any kind at this point in time.

What do you all think about starting with a requirements document?

Thanks, Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, November 10, 2007 9:54 AM
To: Henning Schulzrinne
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

-Jonathan R.

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 12 Nov 2007 09:36:46 +0800

I prefer a requirement draft first. We should ensure that the issues address
in the coming peer protocol should meet the requirements based on our rough
consensus. Without a requirement document, we have no a formal place to
track what have been done in existing proposals and what will be address in
the future. 

Regards!
--
Jiang XingFeng

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Monday, November 12, 2007 7:35 AM
> To: Jonathan Rosenberg; Henning Schulzrinne
> Cc: P2PSIP Mailing List

---

From: "Yao Wang" <[email-masked]>
Date: Mon, 12 Nov 2007 11:32:32 +0800

Hi,
    I agree Marcin's point that the support for client should be considered
at current stage.
    In my memory, the concept of P2PSIP Client and its role have been a
controversial source in the discussion of this maillist. Many people
think Client is not part of P2PSIP system, thus there is no need to define
the concept of P2PSIP Client or a separate protocol called P2PSIP Client
protocol.
   However, in my and my colleagues' opinions, we argue that P2PSIP Client
is indispensable. Generally speaking, the necessity of P2PSIP Client comes
from the heterogeneity among all the nodes which want or need to use P2PSIP
services. Some nodes are unable or unsuitable to join the P2PSIP Overlay as
peers due to the heterogeneity of DHT algorithms, heterogeneity among P2PSIP
nodes and other heterogeneity.
   Currently, we are working on a draft which is dedicated to discuss the
necessity of P2PSIP Client and present a high-level description of our
proposed P2PSIP Client Protocol. This draft will be finished and submitted
soon. Before the submission of this draft, we'd like more discussions of
this topic in the maillist.

   Comments are always welcomed.

On 11/8/07, [email-masked] <[email-masked] >
wrote:
> >From: ext Emil Ivov [mailto: [email-masked] ]

-- 
          Sincerely yours,

Yao Wang

Mobile Life Lab

Beijing University of Posts & Telecommunications
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 12 Nov 2007 12:03:26 +0800

Hi,
 
    Agree with your viewpoint about P2PSIP client.
    We submitted a draft named with "P2PSIP client protocol" in 10th November 2007, it should be available soon in http://tools.ietf.org/wg/p2psip/.
    It mainly describes the basic functions of P2PSIP client protocol in accordance with P2PSIP WG charter (http://www.ietf.org/html.charters/p2psip-charter.html). It reuses the P2PSIP peer protocol (http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) to implement those functions.
    Any comment is appreciated.
 
Best regards,
Hewen

  _____  

From: Yao Wang [mailto:[email-masked]] 
Sent: 2007年11月12日 11:33
To: [email-masked]
Cc: [email-masked]
Subject: Re: [P2PSIP] Proposal for progress on protocols

Hi, 
    I agree Marcin's point that the support for client should be considered at current stage.
    In my memory, the concept of P2PSIP Client and its role have been a controversial source in the discussion of this maillist. Many people think Client is not part of P2PSIP system, thus there is no need to define the concept of P2PSIP Client or a separate protocol called P2PSIP Client protocol. 
   However, in my and my colleagues' opinions, we argue that P2PSIP Client is indispensable. Generally speaking, the necessity of P2PSIP Client comes from the heterogeneity among all the nodes which want or need to use P2PSIP services. Some nodes are unable or unsuitable to join the P2PSIP Overlay as peers due to the heterogeneity of DHT algorithms, heterogeneity among P2PSIP nodes and other heterogeneity. 
   Currently, we are working on a draft which is dedicated to discuss the necessity of P2PSIP Client and present a high-level description of our proposed P2PSIP Client Protocol. This draft will be finished and submitted soon. Before the submission of this draft, we'd like more discussions of this topic in the maillist. 

On 11/8/07, [email-masked] <[email-masked]  <mailto:[email-masked]> > wrote: 

Hi all,

Marcin

>From: ext Emil Ivov [mailto:  <mailto:[email-masked]> [email-masked] ]
> [email-masked] <mailto:[email-masked]> 
>https://www1.ietf.org/mailman/listinfo/p2psip  <https://www1.ietf.org/mailman/listinfo/p2psip> 
>

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

-- 
          Sincerely yours, 

Yao Wang

Mobile Life Lab

---

From: "Wei Gengyu" <[email-masked]>
Date: Mon, 12 Nov 2007 17:28:29 +0800

Hi, all

I have a question.

A peer in a P2PSIP overlay can be the proxy of a mobile client. 
Could SIP(rfc3261) be used between the client and the proxy Peer instead of defining a new protocol?

Best regards,

Gengyu

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 08, 2007 5:28 PM
Subject: RE: [P2PSIP] Proposal for progress on protocols

Hi all,

Marcin

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 12 Nov 2007 18:52:41 +0800

Hi,

    In my understanding according to P2PSIP Reference model defined in "Concepts and Terminology for Peer to Peer SIP"
(draft-ietf-p2psip-concepts-00), SIP is not eligible to act as a communication protocol between a peer and its associated
clients.
    Further, in detail, considering those reasons as below, SIP is not eligible to be chosen as the signal underlying
protocol of P2PSIP client protocol:
   (1). SIP does not exist between a client and its associated peer at some scenarios.
   According to P2PSIP Overlay Reference Model depicted in Figure 1 in "Concepts and Terminology for Peer to Peer SIP"
(draft-ietf-p2psip-concepts-00), P2PSIP client protocol runs between a peer without any SIP entity and a client with a SIP
entity, the peer does not recognize SIP protocol, SIP is not eligible to act as the signal underlying protocol of P2PSIP
client protocol.

   (2). SIP is not a general Remote Procedure Call (RPC).
   A P2PSIP client protocol on top of SIP acts as a remote procedure call (RPC) mechanism.  The SIP guidelines document
[RFC4485] prohibits the use of SIP as a RPC mechanism.

   (3). SIP is not a general purpose transfer protocol.
   One of P2PSIP client protocol main tasks is to transfer resource object and its content, those contents is irrelevant to
SIP.  SIP's operation and the SIP guideline document [RFC4485] prohibit sending large amounts of data unrelated to SIP's
operation.

   (4). SIP is not a lookup protocol.
   SIP is not a lookup protocol; it relies on DNS to locate an appropriate SIP server.  Insert and lookup functionality is
essential for any P2PSIP client protocol.  Using SIP as a peer-to-peer protocol requires integrating lookup functionality
into SIP which goes against its design philosophy.

Best regards,
Hewen

-----Original Message-----
From: Wei Gengyu [mailto:[email-masked]]
Sent: 2007?11?12? 17:28
To: [email-masked]
Cc: [email-masked]
Subject: Re: [P2PSIP] Proposal for progress on protocols

Hi, all

I have a question.

Best regards,

Gengyu

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 08, 2007 5:28 PM
Subject: RE: [P2PSIP] Proposal for progress on protocols

Hi all,

Marcin

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 12 Nov 2007 19:01:38 +0800

Hi,

    A client can contribute its storage capacity to its associated peer, certainly, it gets P2PSIP overlay service through
its associated peer, as you mentioned, the peer act as a proxy for the client.
    In my opinion, maybe P2PSIP client protocol does not emerge as a distinct protocol at last, for example, it emerge a
subset of P2PSIP peer protocol.

Thanks,
Hewen
-----Original Message-----
From: Wei Gengyu [mailto:[email-masked]]
Sent: 2007?11?12? 17:28
To: [email-masked]
Cc: [email-masked]
Subject: Re: [P2PSIP] Proposal for progress on protocols

Hi, all

I have a question.

Best regards,

Gengyu

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 08, 2007 5:28 PM
Subject: RE: [P2PSIP] Proposal for progress on protocols

Hi all,

Marcin

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 12 Nov 2007 12:29:31 +0100

Hi,

On 12/11/2007, Zheng Hewen <[email-masked]> wrote:
> A client can contribute its storage capacity to its associated peer

IMHO we should consider 3 main actors:
- Peers: nodes to perform the overlay and offer storage and routing
capabilities. [coupled with one or more SIP entities] -> interact with
other peers using peer protocol
- Clients: nodes to contribute its storage capacity to its associated
peer [coupled with SIP UA] -> interact with peers using client
protocol
- SIP [RFC3161] UA with no other capabilities -> interact with peers using SIP

Clients and SIP UA will reach P2PSIP overlay through peers. While
Clients will store some information, peers will store information on
behalf of SIP UA (e.g. preferences).

We should also consider how clients will interact, if directly -client
protocol- or using a broker peer.

I think this and other philosophical issues should be addressed in
order to reach a consensus and update the concepts document.

Thanks,
Victor Pascual

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 12 Nov 2007 20:47:05 +0800

Hi,

     Agree with your opinion which is compatible with P2PSIP Reference Model.
     I suggest that we could adopt P2PSIP Reference Model defined in draft-ietf-p2psip-concepts-00 as the primitive baseline 
to reach a consensus and update the concepts document.

Tahnks,
Hewen

-----Original Message-----
From: Victor Pascual ¨¢vila [mailto:[email-masked]]
Sent: 2007Äê11ÔÂ12ÈÕ 19:30
To: Zheng Hewen
Cc: Wei Gengyu; [email-masked]; [email-masked]
Subject: Re: [P2PSIP] Proposal for progress on protocols

Hi,

IMHO we should consider 3 main actors:
- Peers: nodes to perform the overlay and offer storage and routing capabilities. [coupled with one or more SIP entities] -> 
interact with other peers using peer protocol
- Clients: nodes to contribute its storage capacity to its associated peer [coupled with SIP UA] -> interact with peers using 
client protocol
- SIP [RFC3161] UA with no other capabilities -> interact with peers using SIP

Clients and SIP UA will reach P2PSIP overlay through peers. While Clients will store some information, peers will store 
information on behalf of SIP UA (e.g. preferences).

I think this and other philosophical issues should be addressed in order to reach a consensus and update the concepts 
document.

Thanks,
Victor Pascual

---

From: "Wei Gengyu" <[email-masked]>
Date: Mon, 12 Nov 2007 22:55:10 +0800

Hi, 

SIP has been widely used between SIP client and proxy or servers, 
and it is easy to get some testbed results.  

And we have to see the fact that there are many mobile terminals installed with SIP UA.
When considering the mobile terminal as a client of P2PSIP overlay, 
the SIP protocol is cheap and suitable. 

While in "Concepts and Terminology for Peer to Peer SIP draft-willis-p2psip-concepts-04"
or "Concepts and Terminology for Peer to Peer SIP" (draft-ietf-p2psip-concepts-00),
"An overlay may or may not also include one or more nodes called
   P2PSIP Clients.  The role of a client in the P2PSIP model is still
   under discussion, with a number of suggestions for roles being put
   forth, and some arguing that clients are not needed at all.  However,
   if they exist, then people agree that they will also be able to store
   and retrieve information from the overlay.  Section 5.5 discusses the
   possible roles of a client in more detail."

In section 5.5:
"In one alternative, a client interacts with the P2PSIP overlay
   through an associated peer (or perhaps several such peers) using the
   Client Protocol.  The client does not run the distributed database
   algorithm, does not store resource records, and is not involved in
   routing messages to other peers or clients.  Though interactions with
   its associated peer, a client can insert, modify, examine, and remove
   resource records.  A client can also send SIP messages to its
   associated peer for routing through the overlay.  In this
   alternative, a client is a node that wants to take advantage of the
   overlay, but is unable or unwilling to contribute resources back to
   the overlay.

   One way to realize this alternative is for a peer to behave as
   [RFC3261] proxy/registrar.  Clients then use standard SIP mechanisms
   to add, update, and remove registrations and to send SIP messages to
   peers and other clients.  If this is done, there is no need for a
   separate Client Protocol and no need for P2PSIP to define a distinct
   "P2PSIP Client" concept."

   And there are also second and third alternatives. 

My opinion is that adopting SIP between the client and the associated proxy Peer
will be simplify the facilities to support mobile clients in the reference model.

Best regards,

Gengyu

---

From: Philip Matthews <[email-masked]>
Date: Mon, 12 Nov 2007 11:37:44 -0500

> instead of defining a new protocol?

This is in fact a long-running proposal.

The answer to this question depends on whether you are interested in  
using a P2PSIP overlay for just SIP, or whether you think our work  
should be more general. If you are interested in just SIP, then this  
is an excellent suggestion. However, if you are interested in  
protocols other than SIP, then this idea doesn't work.

Up until about Jan 2007, most of the active players in this group  
seemed to be primarily interested in just SIP. However, this year has  
seen a rise in interest in non-SIP usages.

However, most (all?) of the currently active proposals are not  
considering clients right now. Personally, I think this is because  
people are still trying to figure out how peers work.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Mon, 12 Nov 2007 11:40:10 -0500

On 12-Nov-07, at 06:01 , Zheng Hewen wrote:

>
>     In my opinion, maybe P2PSIP client protocol does not emerge as  
> a distinct protocol at last, for example, it emerge a

The WG has agreed that, _if_ there is a client protocol, then it  
should be a logical subset of the peer protocol. Here logical means  
that it may have different syntax, but you cannot do more as a client  
than you can as a peer.

This is documented in the Concepts draft.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Mon, 12 Nov 2007 11:45:15 -0500

On 12-Nov-07, at 07:47 , Zheng Hewen wrote:

>      I suggest that we could adopt P2PSIP Reference Model defined  
> in draft-ietf-p2psip-concepts-00 as the primitive baseline

I don't understand what you are suggesting.

The Reference Model in section 3 of draft-ietf-p2psip-concepts-00 is  
supposed to reflect current group consensus. That means it is  
_already_ adopted, and the Concepts draft is _already_ up-to-date on  
this issue.

- Philip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Nov 2007 14:57:30 -0800

> people are still trying to figure out how peers work.

Just as a side note, ASP support clients talking to peers using a  
subset of the protocol that peers use to talk to each other.

---

From: "Yao Wang" <[email-masked]>
Date: Tue, 13 Nov 2007 09:36:53 +0800

Hi, Philip and folks
	Some comments to your points.
	"If you are interested in just SIP, then this is an excellent suggestion. However, if you are interested in protocols other than SIP, then this idea doesn't work."
	Personally, I think the relationship between SIP and other protocols is complementary rather than conflictive. SIP can be utilized to exchange information, such as the detailed parameters of other services other than SIP, between clients and peers. If a client is interested in a service which is provided by a particular protocol not SIP, this client could get the detailed parameters for accessing the service using SIP, for example, if the client want to access FTP services in P2PSIP Overlay, it can get the IP address, port number, available user name and(or) password, etc. In this example, after getting all these parameters, the client can access the service using FTP. SIP is used for service location and the other protocols are used for providing particular services. Therefore, that relationship between SIP and other protocols is complementary rather than conflictive. 
	Of course, a completely new protocol can be used for this function, but SIP has been widely used, why not reuse it? 
	One possible way to implement this is by extending SIP with new Sip Event Packages. We have submitted a new draft, named as "A SIP-based P2PSIP Client Protocol" (http://www.ietf.org/internet-drafts/draft-li-p2psip-client-protocol-00.txt) 	In this draft, we explained our viewpoints on the functions of P2PSIP client and some key requirements on the proposed client protocol.

Yao Wang 
Mobile Life New Media Lab, BUPT

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 12:38 AM
To: Wei Gengyu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

- Philip

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 13 Nov 2007 09:44:26 +0800

Hi,

   Please see inline....

Best regards,
Hewen

-----Original Message-----
From: Wei Gengyu [mailto:[email-masked]]
Sent: 2007Äê11ÔÂ12ÈÕ 22:55
To: Zheng Hewen
Cc: [email-masked]
Subject: Re: [P2PSIP] Proposal for progress on protocols

Hi,

SIP has been widely used between SIP client and proxy or servers, and it is easy to get some testbed results.

And we have to see the fact that there are many mobile terminals installed with SIP UA.
When considering the mobile terminal as a client of P2PSIP overlay, the SIP protocol is cheap and suitable.

[Hewen] You are right. If a peer acts as SIP proxy, then the unmodified SIP protocol can completely act as the communication
protocol between the peer and its associated clients, at this time, a client protocol is not necessary. If a peer does not
couple with any SIP entity as in Reference model, a client protocol is desire and SIP is not the choice since the peer Does
Not couple with a SIP entity. P2PSIP is used in the other scenarios besides mobile communication, do you think so? A suite
of general P2PSIP protocols should be preferred. In IETF69, it is consensus that separate P2P layer is preferred than
extending SIP considering some known limitation of extension of SIP protocol.

or "Concepts and Terminology for Peer to Peer SIP" (draft-ietf-p2psip-concepts-00), "An overlay may or may not also include
one or more nodes called

In section 5.5:

[Hewen] The original Concept document need modification, IMHO, it is primitive somewhere, the definition of a client
character from the Reference model is clear, but the Section 5.5 describes some confused behaviors. In detail, the first
alternative potentially that the peer couples with a SIP entity(proxy/registrar), hence SIP protocol is enough and a client
protocol is not necessary, at the same time any extension of SIP protocol is not necessary, but  P2PSIP provides an
alternative to the SIP discovery process of RFC 3263, it means that a SIP entity is not mandatory for a peer, the true
requirement for a client protocol between a peer without any SIP entity and a client with a SIP UA; the second alternative
requests a client can contribute its storage capacity to its associated peer, in this scenario, if SIP is adopted as the
underlying protocol for the client protocol, we have to extend SIP protocol, but the extension is limited/prohibited by
RFC4485. The third alternative is strange, it thinks that a client has a "Peer-ID", but in IETF69, we think that a client is
a non-overlay-routing node (e.g., the P2PSIP overlay is transparent to any client). In summary, for a client protocol
between a peer and its associated clients, we only need to think about two scenarios: (1). the interaction between a peer
without any SIP entity and a client with SIP UA; (2). a client contributes its storage capacity to its associated peer, and
at the same time, SIP is already not a choice. We need to update Section 5.5 in Concept document according to the Reference
model.

My opinion is that adopting SIP between the client and the associated proxy Peer will be simplify the facilities to support
mobile clients in the reference model.

Best regards,

Gengyu

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 13 Nov 2007 10:00:11 +0800

Hi,

    Please see inline...

Best regards,
Hewen

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]]
Sent: 2007?11?13? 0:38
To: Wei Gengyu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

The answer to this question depends on whether you are interested in using a P2PSIP overlay for just SIP, or whether you
think our work should be more general. If you are interested in just SIP, then this is an excellent suggestion. However, if
you are interested in protocols other than SIP, then this idea doesn't work.
[Hewen] Agree.

Up until about Jan 2007, most of the active players in this group seemed to be primarily interested in just SIP. However,
this year has seen a rise in interest in non-SIP usages.

However, most (all?) of the currently active proposals are not considering clients right now. Personally, I think this is
because people are still trying to figure out how peers work.
[Hewen]IMHO, a P2PSIP client character is more simple and clear than a peer, we can clarify the P2PSIP client definition and
character according to the explicit Reference Model in Concept document, in my memory, some proposals such as P2PP, RELOAD
and ASP mention even describe the behavior of a P2PSIP client. Essentially, the explicit definition of a P2PSIP client can
help to clarify and define the functions of P2PSIP peer protocol, I think that most of players in this group do not want to
continue to see the chaos about the definition of P2PSIP peer and client. At least we can reach the agreement about P2PSIP
client character according to the Reference model before completing standardization of P2PSIP peer protocol. Any comment?
[Hewen]Here are info about P2PSIP client protocol in some Peer protocol.
<P2PP>"Clients can use overlay services through peers.  Multiple clients can participate in the overlay through one peer but
clients can also communicate with multiple peers at the same time.  Client and peers communicate using the same protocol as
peers do, i.e., there is no distinct protocol for client-to-peer and peer-to-peer communication. ..."
<RELOAD>"In this architecture, no P2PSIP Client Protocol is needed, rather unmodified SIP is used for access by non-peers."
<ASP>"A P2P signaling protocol provides its clients with an abstract hash table service between a set of cooperating peers
that form the P2P network. ..."

- Philip

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 13 Nov 2007 10:08:31 +0800

Hi,

    Please see inline...

Best regards,
Hewen

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]]
Sent: 2007?11?13? 0:40
To: Zheng Hewen
Cc: 'Wei Gengyu'; [email-masked]; [email-masked]
Subject: Re: [P2PSIP] Proposal for progress on protocols

On 12-Nov-07, at 06:01 , Zheng Hewen wrote:

>
>     In my opinion, maybe P2PSIP client protocol does not emerge as a
> distinct protocol at last, for example, it emerge a subset of P2PSIP
> peer protocol.

The WG has agreed that, _if_ there is a client protocol, then it should be a logical subset of the peer protocol. Here
logical means that it may have different syntax, but you cannot do more as a client than you can as a peer.
[Hewen]Thanks for you mention first. As you said, we all must abide the agreed WG charter once it is determined^_^  A new
distinct client protocol may not be necessary, but as a subset of the Peer protocol, some semantic extension  of Peer
protocol for the communication protocol between a client and its associated peer may be desired after clarifying the P2PSIP
client character. I think that a distinct document is desired to clarify the functions of the communication protocol between
a client and its associated peer.

- Philip

---

From: "Yao Wang" <[email-masked]>
Date: Tue, 13 Nov 2007 10:16:45 +0800

Agree on "At least we can reach the agreement about P2PSIP client character according to the Reference model before completing standardization of P2PSIP peer protocol"

In my opinion, a document specifying the exact characters of P2PSIP Client and the requirements of P2PSIP Client Protocol based on the consensus of this WG is needed before the standardization of client protocol and peer protocol.

Sincerely yours,
 
Yao Wang 

-----Original Message-----
From: Zheng Hewen [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 10:00 AM
To: 'Philip Matthews'; 'Wei Gengyu'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] Proposal for progress on protocols

Hi,

    Please see inline...

Best regards,
Hewen

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]]
Sent: 2007?11?13? 0:38
To: Wei Gengyu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

- Philip

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 13 Nov 2007 10:18:25 +0800

Hi,

    Please forgive my repeat and straight expression first.
    The original Concept document needs some modification especially on the description of P2PSIP client behaviors.
    IMHO, it is primitive somewhere, the definition of a client character from the Reference model is clear, but the Section
5.5 describes some confused behaviors.
     In detail, the first alternative potentially that the peer couples with a SIP entity(proxy/registrar), hence SIP
protocol is enough and a client protocol is not necessary (as said in RELOAD proposal), at the same time any extension of
SIP protocol is not necessary , but  P2PSIP provides an alternative to the SIP discovery process of RFC 3263, it means that
a SIP entity is not mandatory for a peer, the true requirement for a client protocol between a peer without any SIP entity
and a client with a SIP UA.
     The second alternative requests a client can contribute its storage capacity to its associated peer, in this scenario,
if SIP is adopted as the underlying protocol for the client protocol, we have to extend SIP protocol, but the extension is
limited/prohibited by RFC4485.
     The third alternative is strange, it thinks that a client has a "Peer-ID", but in IETF69, we think that a client is a
non-overlay-routing node (e.g., the P2PSIP overlay is transparent to any client).
      In summary, for a communication protocol (i.e., client protocol) between a peer and its associated clients, we only
need to think about two scenarios: (1). the interaction between a peer without any SIP entity and a client with SIP UA; (2).
a client contributes its storage capacity to its associated peer, and at the same time, SIP is already not a choice.
      We need to update Section 5.5 in Concept document according to the Reference model, (1). If the peer couple with SIP
entity, SIP protocol is enough and at the same time the P2PSIP client protocol also works; (2).If the peer does not couple
with any SIP entity, a P2PSIP client protocol is desired, and at the same time, a client can contribute its storage capacity
to its associated peer.  The P2PSIP overlay network is transparent to any P2PSIP client, a P2PSIP client is
non-overlay-routing node.

Best regards,
Hewen

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]]
Sent: 2007?11?13? 0:45
To: Zheng Hewen
Cc: 'Victor Pascual ??vila'; [email-masked]
Subject: Re: [P2PSIP] Proposal for progress on protocols

On 12-Nov-07, at 07:47 , Zheng Hewen wrote:

>      I suggest that we could adopt P2PSIP Reference Model defined in
> draft-ietf-p2psip-concepts-00 as the primitive baseline to reach a
> consensus and update the concepts document.

The Reference Model in section 3 of draft-ietf-p2psip-concepts-00 is supposed to reflect current group consensus. That means
it is _already_ adopted, and the Concepts draft is _already_ up-to-date on this issue.

- Philip

---

From: "lichun li" <[email-masked]>
Date: Tue, 13 Nov 2007 10:36:53 +0800

I agree with Philip Matthews. We need to identify the role of client first.
IMHO, the basic role of client is: clients use P2PSIP overlay for SIP. If
clients use P2PSIP overlay for SIP only, SIP and its extensions for
P2PSIP can be used as client protocol.
If P2PSIP overlay provides other services or clients may offer services, the
protocols used between clients and peers may include all or some of the
following protocols: SIP, STUN, SIP extensions for P2PSIP and other
protocols. For backward-compatibility, we think SIP should be used to
allow conventional clients using P2PSIP overlay .

-- 
Sincerely yours,

Lichun Li

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Nov 2007 22:56:39 -0500

This is true for P2PP as well. We found little advantage in creating a  
completely separate protocol.

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 11:41:27 -0500

As a working group member, I am encouraged by the debate on the  
existence and nature of the P2PSIP client, and the proposals for a  
Client Protocol.

But as a co-author of the Concepts draft, I think it is premature to  
modify the discussion on Clients in the draft.  It is not that I  
don't want to do this, it is just that I think there is no consensus  
yet on the nature or even existence of clients.

I think we are coming up to the point where there will be a major  
revision to the Concepts draft that will focus in on a specific  
architecture and mechanisms, and that revision may well include a  
major revision in the section on clients. But I don't think it should  
be the revision for this cycle.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 12:26:53 -0500

On 12-Nov-07, at 21:16 , Yao Wang wrote:

> Agree on "At least we can reach the agreement about P2PSIP client  
> character according to the Reference model before completing  
> standardization of P2PSIP peer protocol"
>
> In my opinion, a document specifying the exact characters of P2PSIP  
> Client and the requirements of P2PSIP Client Protocol based on the  
> consensus of this WG is needed before the standardization of client  
> protocol and peer protocol.
>

What I think we need is a client proposal that people feel makes  
sense - not necessarily in the fine details, but in the overall  
direction. The new proposals just published may do that -- let's see  
what people think in Vancouver.

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 13 Nov 2007 11:42:23 -0800

> I think there is no consensus  

>From this list I understand there is less a problem with the existence
of clients, but rather if there should be a separate client protocol. 

Also, some folks mentioned that the client protocol should just be a
subset of the peer protocol.

Is this understanding of the discussions correct?

Given the preponderance of mobile devices, this alone would justify a
new version of the concepts document.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 10:41 AM
To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

- Philip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 13 Nov 2007 21:55:30 +0100

> Is this understanding of the discussions correct?

This is how I understand the discussions.

Considering Peers to offer at least routing and storage capabilities,
some of us understand Clients to offer only storage. In this way, as
said in previous messages, we should consider three main types of
node: peers (nodes to perform the overlay and offer storage and
routing capabilities and they are coupled with one or more SIP
entities), clients (nodes to contribute its storage capacity to its
associated peer and they are coupled with SIP UA) and SIP [RFC3161]
(UA with no other capabilities).

behalf of SIP UA.

Since Peers and Clients would need to exchange some kind of
information, what is a subset of information exchanged between peers +
other possible data with other periodicity, requirements for the
Client protocol can be considered to be different from the Peer
protocol.

Thus,
Peer <---- Peer Protocol ----> Peer
Client <---- Client Protocol ----> Peer
SIP UA <---- SIP [RFC3261] ----> Peer

As an example, I imagine Peers storing 'general' AoR information and
user preferences while Clients would store only 'their buddies' AoR
information.

Thank you,
Victor Pascual

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 13 Nov 2007 15:10:53 -0600

Hi, Jonathan,

>I think Philips presentation and the slides he put together last time were 
>meant to do exactly this kind of thing - to show in what ways various 
>proposals were the same, and where they were different.

I understood Henning's proposal to be a request for more of the same type of 
discussion. That's why I agreed with Henning that this would be helpful.

> every issue for a p2p protocol through a group consensus process, and then 
> assemble the results into a built-from-ground-up working group document. 
> I've seen that process tried before in other groups (midcom, the impp 
> protocols), and in each case it has been a dismal failure, taking a long 
> time and producing results no one liked.

You left out http://en.wikipedia.org/wiki/Frankenstein#Plot, but I'm not 
sure which working group did that one :-)

("I agree with your point here")

> working group item and make changes from there based on discussions. Note 
> that, just because a document is adopted as a working group item doesn't 
> mean it can't be changed. But it does mean that the document is believed 
> to be on the right track and a "good starting point" for producing the 
> final deliverable.

I'm not sure if we've gotten to this point yet, but I agree that this is 
where we should be headed.

As an example of the kind of discussion we need to finish, we had 
conversations about running other peer protocols OVER HIPHOP in Chicago.

I'd like to better understand our range of choices.

Thanks,

Spencer

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 11:20:50 +0800

Hi, all,

          The time in Vancouver is limited and very precious.
          After those discussion about P2PSIP client in the latest mail list, a survey about P2PSIP client charcater/behavior 
among active members in this work group will be very helpful for the further discussion in Vancouver.
          As Victor Pascual ¨¢vila said, there are mainly three types of nodes:
          (1).Peers (nodes to perform the overlay and offer storage and routing capabilities and they are coupled WITH one or 
more SIP entities or WITHOUT any SIP entity, overlay-routing nodes),
          (2).Clients (nodes to contribute its storage capacity to its associated peer and they are coupled with SIP UA, 
non-overlay-routing nodes);
          (3).SIP [RFC3161] (UA with no other capabilities).

           Any comment?

          We suggest that the revised Concept document would clarify the P2PSIP client character if  an agreement about P2PSIP 
client character is reached in the mail list.

Best regards,
Hewen

-----Original Message-----
From: Victor Pascual ¨¢vila [mailto:[email-masked]]
Sent: 2007Äê11ÔÂ14ÈÕ 4:56
To: Henry Sinnreich
Cc: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu; P2PSIP Mailing List
Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols)

Considering Peers to offer at least routing and storage capabilities, some of us understand Clients to offer only storage. In 
this way, as said in previous messages, we should consider three main types of
node: peers (nodes to perform the overlay and offer storage and routing capabilities and they are coupled with one or more SIP 
entities), clients (nodes to contribute its storage capacity to its associated peer and they are coupled with SIP UA) and SIP 
[RFC3161] (UA with no other capabilities).

Clients and SIP UA will reach P2PSIP overlay through peers. While Clients will store some information, peers will store 
information on behalf of SIP UA.

Since Peers and Clients would need to exchange some kind of information, what is a subset of information exchanged between 
peers + other possible data with other periodicity, requirements for the Client protocol can be considered to be different 
from the Peer protocol.

Thus,

As an example, I imagine Peers storing 'general' AoR information and user preferences while Clients would store only 'their 
buddies' AoR information.

Thank you,
Victor Pascual

---

From: "Yao Wang" <[email-masked]>
Date: Wed, 14 Nov 2007 11:28:58 +0800

Yes, you are right.

Currently, the main difference in the debate comes from how to build the client protocol, whether it could be based on SIP, whether it could be a syntax subset of Peer Protocol, or whether it is a separate protocol different from both SIP and Peer Protocol but its function is subset of the functions of Peer Protocol. 

Here are some of my understandings,
1. What services client can get using Client Protocol?
	In my opinion, there are two kinds of services.
	Firstly, from the charter of this WG, this WG "is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP)". It is clearly that SIP service (including locating target user, forwarding SIP messages) is a basic service that P2PSIP Overlay MUST provide. Client Protocol MUST enable client to access this services.
	Secondly, services other than SIP. As mentioned in concept draft, some individual peers may provide services in addition to storage and routing, for example STUN services, to the overlay. However, because clients do not join P2PSIP Overlay, they can not discover these services directly. Therefore, client protocol MUST provide a mean for client to know what services are available in the P2PSIP Overlay and the comprehensive parameters for access these services. After getting these parameters, the client can use other protocols, for example STUN, to access the service, which should be out of the scope of client protocol. 
	To meet the first kind of requirements, SIP is mandatory. When it comes to the second kind of requirements, both SIP and other protocol (e.g. a subset of peer protocol) can work. 
	If the subset of peer protocol is adopted as client protocol (supposing the peer protocol is not SIP-based), the client _has_  _to_ run two protocol stacks at the same time, which obviously consumes more resources of client than only running SIP stack. Given the assumption that clients are resource-limited devices, running one more protocol stack may cause the degradation of its performances.
	Thus, why not use SIP and SIP extensions to satisfy both requirements? why not kill two birds with one stone?  Currently, many mobile devices have been equipped with SIP; the reuse of SIP in client protocol not only reduces the resource needed on client devices but also reduces the implementation complexity of client protocol. 

2. What services peer can get using Client Protocol?
	It seems that people in this list accept that the client should contribute its storage capacity to peers. In my opinion, the client can provide more service than that. Here is one possible example which is described in our proposed draft ("A SIP-based P2PSIP Client Protocol")
	"For example, a conferences server wants to provide conference services to nodes in a P2PSIP system.  Because the decoding, mixture and encoding of multiple media streams can be quite a heavy load for its computational resources, this conference server may choose not to join in the P2PSIP overlay. Thus, some extra    resources, which would be used for the maintenance of P2P overlay if the server joined overlay, can be utilized for providing better conference services."
	Therefore, the client protocol must be extensible for supporting any possible services. SIP is a well-developed extensible signal protocol, thus, we propose to build client protocol based on SIP.

Any comments?

Sincerely yours,
 
Yao Wang 
Mobile Life and New Media Lab, BUPT

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 3:42 AM
To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu
Cc: P2PSIP Mailing List
Subject: client protocol ([P2PSIP] Proposal for progress on protocols)

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 10:41 AM
To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

- Philip

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 11:51:14 +0800

Hi, all,

        From current discussion in the mail list, nobody doubts the Reference Model defined the Concept document, nobody
doubts the existence of clients. Do I understand it correctly? The Reference model is clear, why do we see the description
about P2PSIP client behavior in Section 5.5 of the Concept document?
        The difference in only about the form of client protocol, P2PP and ASP think that the client protocol is the subset
of the peer protocol; RELOAD thinks that unmodified SIP is enough and separate client protocol is not necessary, any other?
But those do not impact the try to reach agreement on the P2PSIP client character/behavior.

         As discussed in IETF69, peers are overlay-routing nodes, clients are non-overlay-routing nodes, it is not feasible
that a client has a "Peer-ID" as described in the 3rd alternative in Section 5.5 of the Concept document. Clients couple
with SIP UA, peers couple with SIP entity or without any SIP entity as Reference model; the unmodified SIP is enough and a
separate client protocol is not needed when the associate peer couple with SIP entity (SIP proxy/registrar) as demonstrated
in RELOAD; in the other scenarios, a client protocol is desired as the communication protocol between a client and its
associated peer, but the client protocol may emerge as one part of peer protocol, hence we can make a consensus as above,
any comment?

         The biggest problem may be about the function of P2PSIP client protocol, we do not have an explicit agreement yet,
in fact, the same thing exists for P2PSIP peer protocol, and then it becomes very difficult to develop peer protocol and
client protocol.
         Sometimes, I think that we really need an I-D about P2PSIP framework to define the functions of P2PSIP peer/client
protocols.

Best regards,
Hewen

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: 2007?11?14? 3:42
To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu
Cc: P2PSIP Mailing List
Subject: client protocol ([P2PSIP] Proposal for progress on protocols)

>From this list I understand there is less a problem with the existence of clients, but rather if there should be a separate
client protocol.

Also, some folks mentioned that the client protocol should just be a subset of the peer protocol.

Given the preponderance of mobile devices, this alone would justify a new version of the concepts document.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]]
Sent: Tuesday, November 13, 2007 10:41 AM
To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

As a working group member, I am encouraged by the debate on the existence and nature of the P2PSIP client, and the proposals
for a Client Protocol.

But as a co-author of the Concepts draft, I think it is premature to modify the discussion on Clients in the draft.  It is
not that I don't want to do this, it is just that I think there is no consensus yet on the nature or even existence of
clients.

I think we are coming up to the point where there will be a major revision to the Concepts draft that will focus in on a
specific architecture and mechanisms, and that revision may well include a major revision in the section on clients. But I
don't think it should be the revision for this cycle.

- Philip

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 12:04:19 +0800

Hi,

    Frankly, I think that reaching an agreement about P2PSIP client behavior/character is necessary before developing P2PSIP 
client protocol, otherwise it will be very difficult to develop P2PSIP client protocol.
    By the way, there are many ways to implement the required services such as SIP, SIP-based client protocol is one choice 
^_^

Best regards,
Hewen

-----Original Message-----
From: Yao Wang [mailto:[email-masked]]
Sent: 2007Äê11ÔÂ14ÈÕ 11:29
To: 'Henry Sinnreich'; 'Philip Matthews'; 'lichun li'; 'Zheng Hewen'; 'Wei Gengyu'
Cc: 'P2PSIP Mailing List'
Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols)

Yes, you are right.

Currently, the main difference in the debate comes from how to build the client protocol, whether it could be based on SIP, 
whether it could be a syntax subset of Peer Protocol, or whether it is a separate protocol different from both SIP and Peer 
Protocol but its function is subset of the functions of Peer Protocol.

Here are some of my understandings,
1. What services client can get using Client Protocol?
	In my opinion, there are two kinds of services.
	Firstly, from the charter of this WG, this WG "is chartered to develop protocols and mechanisms for the use of the Session 
Initiation Protocol (SIP)". It is clearly that SIP service (including locating target user, forwarding SIP messages) is a 
basic service that P2PSIP Overlay MUST provide. Client Protocol MUST enable client to access this services.
	Secondly, services other than SIP. As mentioned in concept draft, some individual peers may provide services in addition to 
storage and routing, for example STUN services, to the overlay. However, because clients do not join P2PSIP Overlay, they can 
not discover these services directly. Therefore, client protocol MUST provide a mean for client to know what services are 
available in the P2PSIP Overlay and the comprehensive parameters for access these services. After getting these parameters, 
the client can use other protocols, for example STUN, to access the service, which should be out of the scope of client 
protocol.
	To meet the first kind of requirements, SIP is mandatory. When it comes to the second kind of requirements, both SIP and 
other protocol (e.g. a subset of peer protocol) can work.
	If the subset of peer protocol is adopted as client protocol (supposing the peer protocol is not SIP-based), the client 
_has_  _to_ run two protocol stacks at the same time, which obviously consumes more resources of client than only running SIP 
stack. Given the assumption that clients are resource-limited devices, running one more protocol stack may cause the 
degradation of its performances.
	Thus, why not use SIP and SIP extensions to satisfy both requirements? why not kill two birds with one stone?  Currently, 
many mobile devices have been equipped with SIP; the reuse of SIP in client protocol not only reduces the resource needed on 
client devices but also reduces the implementation complexity of client protocol.

2. What services peer can get using Client Protocol?
	It seems that people in this list accept that the client should contribute its storage capacity to peers. In my opinion, the 
client can provide more service than that. Here is one possible example which is described in our proposed draft ("A SIP-based 
P2PSIP Client Protocol")
	"For example, a conferences server wants to provide conference services to nodes in a P2PSIP system.  Because the decoding, 
mixture and encoding of multiple media streams can be quite a heavy load for its computational resources, this conference 
server may choose not to join in the P2PSIP overlay. Thus, some extra    resources, which would be used for the maintenance of 
P2P overlay if the server joined overlay, can be utilized for providing better conference services."
	Therefore, the client protocol must be extensible for supporting any possible services. SIP is a well-developed extensible 
signal protocol, thus, we propose to build client protocol based on SIP.

Any comments?

Sincerely yours,

Yao Wang

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Wednesday, November 14, 2007 3:42 AM
To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu
Cc: P2PSIP Mailing List
Subject: client protocol ([P2PSIP] Proposal for progress on protocols)

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]]
Sent: Tuesday, November 13, 2007 10:41 AM
To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Proposal for progress on protocols

But as a co-author of the Concepts draft, I think it is premature to modify the discussion on Clients in the draft.  It is not 
that I don't want to do this, it is just that I think there is no consensus yet on the nature or even existence of clients.

- Philip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 14 Nov 2007 09:16:07 +0100

On 14/11/2007, Zheng Hewen <[email-masked]> wrote:
> Frankly, I think that reaching an agreement about P2PSIP client behavior/character is necessary before developing P2PSIP client protocol, otherwise it will be very difficult to develop P2PSIP client protocol.

I'm fully agree with you.
Defining what tasks P2PSIP peers perform, we should be able to define
the P2PSIP client behaviour and requirements.
Since a peer should be able to change its role and become a Client, I
consider using the same protocol stack for Peer Protocol and Client
Protocol what is not necessary SIP-based -depending on requirements-.

Thanks,
-- 
Victor Pascual Ávila

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 16:27:47 +0800

Hi,

    I do think so, too.
    The same protocol stack for Peer protocol and Client protocol is more efficient and simple.

Best regards,
Hewen

> Sent: 2007Äê11ÔÂ14ÈÕ 16:16
> To: Zheng Hewen
> Cc: Yao Wang; Henry Sinnreich; Philip Matthews; lichun li;
> Wei Gengyu; P2PSIP Mailing List
> > Frankly, I think that reaching an agreement about P2PSIP
> client behavior/character is necessary before developing
> P2PSIP client protocol, otherwise it will be very difficult
> to develop P2PSIP client protocol.
>
>
> Defining what tasks P2PSIP peers perform, we should be able
> to define the P2PSIP client behaviour and requirements.
> Since a peer should be able to change its role and become a
> Client, I consider using the same protocol stack for Peer
> Protocol and Client Protocol what is not necessary SIP-based
> -depending on requirements-.
>
> Thanks,
> --
> Victor Pascual ¨¢vila
>

---

From: "lichun li" <[email-masked]>
Date: Wed, 14 Nov 2007 16:43:05 +0800

SIP protocol is mandatory.
If peer protocol is not SIP based, a peer has to run two protocol stacks.
If client protocol is SIP based, a client only need to run one protocol
stack.

-- 
Sincerely yours,

Lichun Li

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 16:58:44 +0800

Hi,
 
     In my impression, SIP protocol has never been mandatory for the communication protocol between any two P2PSIP nodes.
     I encourage you to read the consensus about the relation of P2PSIP and SIP from IETF69 P2PSIP WG minute
(http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt).
     Hope that it will be helpful for you.
 
Best regards,
Hewen

  _____  

From: lichun li [mailto:[email-masked]] 
Sent: 2007?11?14? 16:43
To: Zheng Hewen
Cc: Victor Pascual ¨?vila; Yao Wang; Henry Sinnreich; Philip Matthews; Wei Gengyu; P2PSIP Mailing List
Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols)

SIP protocol is mandatory. 
If peer protocol is not SIP based, a peer has to run two protocol stacks.
If client protocol is SIP based, a client only need to run one protocol stack.

Hi,

   I do think so, too.

Best regards,
Hewen

-- 
Sincerely yours,

Lichun Li

---

From: "lichun li" <[email-masked]>
Date: Wed, 14 Nov 2007 17:18:25 +0800

According to concept draft, "Since P2PSIP is about peer-to-peer networks for
real-time communication, it is expected that most (if not all) peers and
   clients will be coupled with SIP entities." So I think SIP protocol is
mandatory in most nodes (if not all).

On 11/14/07, Zheng Hewen <[email-masked]> wrote:
>
>  Hi,
>
>      In my impression, SIP protocol has never been mandatory for the
> communication protocol between any two P2PSIP nodes.
>      I encourage you to read the consensus about the relation of P2PSIP
> and SIP from IETF69 P2PSIP WG minute (
> http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt).
>  ------------------------------
> *From:* lichun li [mailto:[email-masked]]
> *Sent:* 2007年11月14日 16:43
> *To:* Zheng Hewen
> *Cc:* Victor Pascual ¨￠vila; Yao Wang; Henry Sinnreich; Philip Matthews;
> *Subject:* Re: client protocol ([P2PSIP] Proposal for progress on
> protocols)
>
>

-- 
Sincerely yours,

Lichun Li

---

From: "Wei Gengyu" <[email-masked]>
Date: Sat, 17 Nov 2007 17:20:33 +0800

Hi, 

As far as I know, 
SIP have been standardized and deployed in a lot of PCs and mobile terminals.
SIP is already there while P2PSIP client protocol is under discussion.

Adopting SIP is more easier to allow any terminal to access P2PSIP overlay than another new protocols.
And I do not see any harmful to P2PSIP overlay if SIP is used in client.

I also agree with Victor Pascual Ávila and the Concept draft need updating.

Gengyu

  ----- Original Message ----- 
  From: Zheng Hewen 
  To: 'lichun li' 
  Cc: 'Victor Pascual ¨?vila' ; 'Yao Wang' ; 'Henry Sinnreich' ; 'Philip Matthews' ; 'Wei Gengyu' ; 'P2PSIP Mailing List' 
  Sent: Wednesday, November 14, 2007 4:58 PM
  Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols)

  Hi,

       In my impression, SIP protocol has never been mandatory for the communication protocol between any two P2PSIP nodes.
       I encourage you to read the consensus about the relation of P2PSIP and SIP from IETF69 P2PSIP WG minute (http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt).
       Hope that it will be helpful for you.

  Best regards,
  Hewen

----------------------------------------------------------------------------
    From: lichun li [mailto:[email-masked]] 
    Sent: 2007年11月14日 16:43
    To: Zheng Hewen
    Cc: Victor Pascual ¨￠vila; Yao Wang; Henry Sinnreich; Philip Matthews; Wei Gengyu; P2PSIP Mailing List
    Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols)

         I do think so, too.

      Best regards,
      Hewen

    -- 
    Sincerely yours,

    Lichun Li

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 17:29:11 +0800

Hi,
 
   You are right, "Since P2PSIP is about peer-to-peer networks for real-time communication, it is expected that most (if not all) peers and clients will be coupled with SIP entities."
   You also notice the limitation, i.e. "most (if not all) ". Some peers couple with SIP entity, but some do not, as Reference model, SIP is not mandatory for those peer without any SIP entity, those peers without any SIP entity only participate P2PSIP overlay network and contribute its storage capacity.
   I do think that SIP is useful as the communication protocol between a peer with SIP entity(proxy/registrar) and its associated clients with SIP UA, but it is only one choice.
 
Best regards,
Hewen

  _____  

Sent: 2007年11月14日 17:18

According to concept draft, "Since P2PSIP is about peer-to-peer networks for real-time communication, it is expected that most (if not all) peers and
   clients will be coupled with SIP entities." So I think SIP protocol is mandatory in most nodes (if not all). 

Hi,
 
     In my impression, SIP protocol has never been mandatory for the communication protocol between any two P2PSIP nodes.
     I encourage you to read the consensus about the relation of P2PSIP and SIP from IETF69 P2PSIP WG minute ( http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt).
     Hope that it will be helpful for you. 
 
Best regards,
Hewen

  _____  

 

On 11/14/07, Zheng Hewen <[email-masked] > wrote: 

Hi,

   I do think so, too.

Best regards,
Hewen

> From: Victor Pascual ¨¢vila [mailto:  <mailto:[email-masked]> [email-masked]]

-- 
Sincerely yours,

Lichun Li

-- 
Sincerely yours,

Lichun Li

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 17:32:05 +0800

Hi,
 
    In fact, we think that any P2PSIP client couples with SIP UA, SIP is not harmful for P2PSIP clients.
    Agree with your opinion that Concept draft needs been updated.
 
Best regards,
Hewen

  _____  

Sent: 2007年11月17日 17:21

Hi, 
 
As far as I know, 

 
Gengyu

----- Original Message ----- 
From: Zheng Hewen <mailto:[email-masked]>  
To: 'lichun li' <mailto:[email-masked]>  
Cc: 'Victor Pascual ¨?vila' <mailto:[email-masked]>  ; 'Yao  <mailto:[email-masked]> Wang' ; 'Henry Sinnreich' <mailto:[email-masked]>  ; 'Philip Matthews' <mailto:[email-masked]>  ; 'Wei  <mailto:[email-masked]> Gengyu' ; 'P2PSIP  <mailto:[email-masked]> Mailing List' 
Sent: Wednesday, November 14, 2007 4:58 PM
Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols)

Hi,

Best regards,
Hewen

  _____  

Hi,

   I do think so, too.

Best regards,
Hewen

-- 
Sincerely yours,

Lichun Li

---

From: "lichun li" <[email-masked]>
Date: Wed, 14 Nov 2007 17:40:04 +0800

Yes, i notice the limitation. We have to identify the role of client first.
The concept draft currently list 3 choices of client roles. I think
maybe different clients with different roles might coexist in P2PSIP.

On 11/14/07, Zheng Hewen <[email-masked]> wrote:
>
>  Hi,
>
>    You are right, "Since P2PSIP is about peer-to-peer networks for
> clients will be coupled with SIP entities."
>    You also notice the limitation, i.e. "most (if not all) ". Some peers
> couple with SIP entity, but some do not, as Reference model, SIP is not
> mandatory for those peer without any SIP entity, those peers without any SIP
> entity only participate P2PSIP overlay network and contribute its storage
> capacity.
>    I do think that SIP is useful as the communication protocol between a
> peer with SIP entity(proxy/registrar) and its associated clients with SIP
> UA, but it is only one choice.
>
> Best regards,
> Hewen
>
>
> *Sent:* 2007年11月14日 17:18
> *To:* Zheng Hewen
> *Cc:* Victor Pascual ¨?vila; Yao Wang; Henry Sinnreich; Philip Matthews;
>  According to concept draft, "Since P2PSIP is about peer-to-peer networks
> for real-time communication, it is expected that most (if not all) peers and
> > > > From: Victor Pascual ¨¢vila [mailto: [email-masked]]

-- 
Sincerely yours,

Lichun Li

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 14 Nov 2007 17:49:28 +0800

"We have to identify the role of client first".
Yeah, We come to the same point at last.
Are all 3 choice of client role rational? Considering the third alternative, if a client occupy a "Peer-ID", is the namespace fully available for peers and resource-records? is there any difference between a peer and a client?
The concept document need updating to clarify P2PSIP client character, do you think so?

  _____  

Sent: 2007年11月14日 17:40

Yes, i notice the limitation. We have to identify the role of client first. The concept draft currently list 3 choices of client roles. I think maybe different clients with different roles might coexist in P2PSIP. 

Hi,

Best regards,
Hewen

  _____  

To: Zheng Hewen

Hi,

Best regards,
Hewen

  _____  

 

Hi,

   I do think so, too.

Best regards,
Hewen

-- 
Sincerely yours,

Lichun Li

-- 
Sincerely yours,

Lichun Li

-- 
Sincerely yours,

Lichun Li

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 14 Nov 2007 11:29:09 +0100

> mandatory in most nodes (if not all).

I understand peers as being full backward compatible with SIP -since
SIP RFC3261 UA would join the overlay using peers-, AFAIU It does not
mean that SIP should be mandatory used for peers' communication.

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 14 Nov 2007 10:07:59 -0500

My comments are inline.

> non-overlay-routing nodes);

Clients may be coupled with one or more SIP entities or none.

>           (3).SIP [RFC3161] (UA with no other capabilities).
When we talk about the overlay, this kind of node is irrelevant.
The overlay (protocol) nodes and SIP entities are independent of each other.
Please don't mix them.

> client character is reached in the mail list.

Thanks.

Eunsoo

-- 
Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 14 Nov 2007 10:22:28 -0500

Not at all.
The overlay needs to provide just distributed database functionality
(== distributed storage and search/lookup functionality) and at most
some kind of generic transport/routing functionality. These
functionalities can be well summarized as PUT, GET, and SEND
functions.

Any information about SIP related services such as mapping of SIP URI
to a location(IP address) or nodes providing certain application
functions/services like conferencing server can be stored and looked
up using the Peer (and Client) Protocol. You don't need SIP at all
here.

That is the idea accepted by the group widely. Now all the proposals
about Peer Protocol do not use extensions/variations of SIP.

If we all understand that Client Protocol provides only a subset of
Peer Protocol's functionality and Peer Protocol can be and better be
implemented independently of SIP, why would we need to have SIP for
Client Protocol? It does not make sense to me.

Thanks.

Eunsoo

On Nov 13, 2007 10:28 PM, Yao Wang <[email-masked]> wrote:
>         To meet the first kind of requirements, SIP is mandatory.

 When it comes to the second kind of requirements, both SIP and other
protocol (e.g. a subset of peer protocol) can work.

-- 
Eunsoo

---

From: Zheng Hewen <[email-masked]>
Date: Thu, 15 Nov 2007 09:55:14 +0800

Hi,

   In Reference model defined in the Concept document, there are mainly two types of nodes: peers and clients with SIP UA.
Further, there are two types of peers: peers with some SIP entity and peers without any SIP entity.
   But from the contribution to P2PSIP overlay network, we can think that there are mainly three types of nodes: peers
(participating in overlay, contributing storage capacity), clients (only contributing storage capacity to their associated
peers) and ordinary SIP UAs (without any contribution), is my understanding correct?
   Certainly, ordinary SIP UAs usually are regarded as P2PSIP clients, and essentially SIP usually is regarded one type of
service over P2PSIP overlay layer.
   I think that we need update the Section 5.3 if we reach the agreement about P2PSIP client character according to the
Reference model, any comment?

Best regards,
Hewen

> From: Eunsoo Shim [mailto:[email-masked]]
> Sent: 2007?11?14? 23:08
> To: Zheng Hewen
> Cc: Victor Pascual ¨?vila; Henry Sinnreich; Philip Matthews;
> P2PSIP Mailing List
> Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior
>
> My comments are inline.
>
> >           After those discussion about P2PSIP client in the latest
> > mail list, a survey about P2PSIP client charcater/behavior
> >           (1).Peers (nodes to perform the overlay and offer storage
> > and routing capabilities and they are coupled WITH one or
> >           (2).Clients (nodes to contribute its storage
> capacity to its
> > associated peer and they are coupled with SIP UA,
> non-overlay-routing
> > nodes);
>
> >           We suggest that the revised Concept document
> would clarify
> > the P2PSIP client character if  an agreement about P2PSIP
> > entities), clients (nodes to contribute its storage
> capacity to its associated peer and they are coupled with SIP
> UA) and SIP [RFC3161] (UA with no other capabilities).
> >
> > Clients will store some information, peers will store
> > other possible data with other periodicity, requirements
> for the Client protocol can be considered to be different
> from the Peer protocol.
> >
> > Thus,
> > Client <---- Client Protocol ----> Peer SIP UA <---- SIP [RFC3261]
> > ----> Peer
> >
> > user preferences while Clients would store only 'their

---

From: Philip Matthews <[email-masked]>
Date: Thu, 15 Nov 2007 07:48:41 -0500

On 14-Nov-07, at 20:55 , Zheng Hewen wrote:

> Hi,
>
>    In Reference model defined in the Concept document, there are  
> mainly two types of nodes: peers and clients with SIP UA.
>    But from the contribution to P2PSIP overlay network, we can  
> think that there are mainly three types of nodes: peers
> (participating in overlay, contributing storage capacity), clients  
> (only contributing storage capacity to their associated

Right now, the reference model identifies three types of nodes: (a)  
peers, (b) clients, and (c) SIP UAs that attach via an proxy.

>    Certainly, ordinary SIP UAs usually are regarded as P2PSIP  
> clients, and essentially SIP usually is regarded one type of

This is not actually true. Right now, the concepts draft says that  
defines the client protocol as something OTHER than SIP, in order to  
distinguish (b) and (c) above.

>    I think that we need update the Section 5.3 if we reach the  
> agreement about P2PSIP client character according to the

Yes. Once we reach agreement on what a client should be, a number of  
sections in the Concepts draft will be to be rewritten.

I am still waiting for that agreement.

- Philip

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 15 Nov 2007 07:23:29 -0600

Great minds think alike. Philip just posted a request for a draft on client 
requirements.

Just to agree with Philip on a couple of specifics...

From: "Philip Matthews" <[email-masked]>

>>    In Reference model defined in the Concept document, there are  mainly
>> two types of nodes: peers and clients with SIP UA.
>>    But from the contribution to P2PSIP overlay network, we can  think
>> that there are mainly three types of nodes: peers
>> (participating in overlay, contributing storage capacity), clients  (only
>> contributing storage capacity to their associated

We discussed the "clients contributing storage capacity" idea just before
the Prague IETF. I'm still not sure we have agreement on what clients are
(beyond "nodes that speak a logical subset of the peer protocol"), and I'm
pretty sure that we don't have agreement that clients contribute storage
capacity.

>>    Certainly, ordinary SIP UAs usually are regarded as P2PSIP  clients,
>> and essentially SIP usually is regarded one type of

Philip is correct here. The current version of the application scenarios
draft
(http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt)
distinguishes between these cases as follows:

   P2P Client Support:  Whether the overlay need to support a P2P Client
         protocol, i.e., whether the overlay contains P2P Clients as
         well as Peers.
   Interoperation with CS-SIP:  Whether the overlay must also interact
         with legacy SIP clients and SIP proxies.
         Note that one or more peers in the overlay may also act as PSTN
         gateways.

(HINT: the application scenarios draft includes analysis about whether each 
scenario seems to require "P2P Client Support" and/or "Interoperation with 
CS-SIP" - I don't think any of the draft authors are prejudiced against 
clients, but none of us are strong advocates of clients, so it would be good 
to have client advocates develop opinions about whether that analysis is 
reasonable or not)

>>    I think that we need update the Section 5.3 if we reach the  agreement
>> about P2PSIP client character according to the

David and Brian asked me to lead discussion on clients in Prague (my slides
are at http://www3.ietf.org/proceedings/07mar/slides/p2psip-6.pdf, meeting
minutes are at http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html).

I'd summarize the sense of the room was in Prague as (1) at that time, we 
did not have creditable use cases ("application scenarios") for clients 
contributing storage apacity, and (2) we didn't have agreement within the 
working group on what clients were.

I don't believe the chairs tried to verify the sense of the room on the 
mailing list after the meeting, so we can't say "the working group has 
consensus" about these points, but that's the way things were headed in the 
face-to-face meeting.

Several people in the room at Prague raised their hands and said they would
discuss clients privately. Did that happen? If it did, we need to see text. 
If it didn't, we need to postpone discussion of clients until it does 
happen.

IMO.

Thanks,

Spencer

>From the Prague meeting minutes:

P2PSIP Client Discussion, Spencer Dawkins

What are Clients?  Not garden variety SIP UACs, nor the equivalent of
 "peers."

Issue: Clients as storage nodes.  No credible use case so far; deferred.

[ Discussion ensued at mic.

  Philip: Why do we need P2PSIP clients?  The answer will drive whether or
  not we use them.

  Brian Rosen (as individual): I don't understand P2PSIP clients.  We need
  to get rid of it and focus on normal SIP clients.

  Philip: Those that want P2PSIP Clients need to come up with a good use
  case by Chicago IETF.  If they do not come up by then, the P2PSIP Clients
  go away. ]

Hum - Should the wg work on the normal garden variety SIP UA connected to
      the DHT via some box (a SIP proxy coupled to a peer)?

[ Hum indicated yes.
  Those that want a P2PSIP Client distinct from a normal SIP client need to
  get together and work on use cases. ]

---

From: Philip Matthews <[email-masked]>
Date: Thu, 15 Nov 2007 09:56:40 -0500

On 15-Nov-07, at 08:23 , Spencer Dawkins wrote:

>
> (HINT: the application scenarios draft includes analysis about  
> whether each scenario seems to require "P2P Client Support" and/or  
> "Interoperation with CS-SIP" - I don't think any of the draft  
> authors are prejudiced against clients, but none of us are strong  
> advocates of clients, so it would be good to have client advocates  
> develop opinions about whether that analysis is reasonable or not)

I agree. Right now, I think that most of the most active participants  
in the group are in the "Show me the money" camp. That is, we are not  
opposed to them, but we want to see a good argument for them.

Some people have said "Mobile devices (e.g., handsets) cannot be  
peers for battery reasons or storage reasons or ...". But these are  
just words in the corridor, and not written down. And I keep hearing  
others say "Nonsense, we CAN have mobile peers".

>  get together and work on use cases. ]

Yup.

- Philip

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 15 Nov 2007 09:57:22 -0500

> peers, (b) clients, and (c) SIP UAs that attach via an proxy.

Peers and Clients are components of the overlay.
SIP UA node is just an example of non-overlay node.
There can be other non-overlay nodes like SIP Proxy node, SIP
registrar node, conferencing server node, etc.

If the current concepts draft suggests that SIP UA node is a
fundamental component of overlay equivalent to Peer and Client, the
description should be modified.
The reference model diagram in the concepts draft is just an
illustration of a possible composition of P2PSIP overlays.
P2PSIP overlay may contain only  a subset of the illustrated node
types (if you count non-overlay node types) or more types.

Thanks.

-- 
Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 15 Nov 2007 10:20:42 -0500

I read that some people think we don't need Client node types.
Removing Client node types has the following consequences I can think of now:
- A SIP UA node that is not a Peer must be attached to a Peer that is
coupled to SIP Proxy entity. (please see the difference between 'node'
and 'entity'.). In other words, to support SIP UA nodes to access the
overlay, many (probably most) Peers should be coupled to SIP Proxy
entities. It is an unnecessary requirement for Peers if we define
Client node types. Furthermore, I'd prefer to use the overlay just for
looking up the location of my callee rather than transport my INVITE
messages through the overlay considering the a Proxy entity running on
a Peer may not be so trustworthy. By removing the possibility of a
node to be a Client coupled with SIP UA entity, we are enforcing any
non-Peer SIP UA node to transport INVITE messages through Proxies
running on Peers.
- If we want other types of non-Peer nodes to be able to access the
overlay, we will have to require Peers to implement other entities.
Even though we want to focus on scenarios using SIP, we already agreed
that it would be better to make the overlay generic enough to support
non-SIP applications as long as the overlay can support SIP
applications well. Here is a non-SIP application scenario where Client
node type is useful. A mobile device that uses the overlay for
asynchronous messaging or small file (eg. small resolution photos)
sharing. None of the applications use SIP UA. Such mobile device would
better be a Client than a Peer. Why would we want to prohibit this
kind of application scenarios?

Thanks.

Eunsoo

-- 
Eunsoo

---

From: Gustavo Garcia <[email-masked]>
Date: Thu, 15 Nov 2007 17:13:36 +0100

I agree with the need of Clients, although I disagree with your first point.

> Client node types. 
It is still a requirement to support non-P2PSIP SIP UAs and probably also to
provide interconnection with other SIP networks.

> Furthermore, I'd prefer to use the overlay just for
> messages through the overlay
The INVITE only needs to go from your SIP UA to the first SIP Proxy.  It
doesn't need to be routed through the overlay.
 
> considering the a Proxy entity running on
> a Peer may not be so trustworthy. 
It should be as trustworthy as the peer you have to connect to when you need
to send a lookup if you are a client, isn't it? 

> By removing the possibility of a

> kind of application scenarios?
Fully agree.  I tried to explain the same idea with the example of the Buddy
List storage which would probably require XCAP proxies attached to the peers
if we don't have a Client Protocol.   In my opinion, having a Client
Protocol should simplify the deployment of future services like those (we
are somehow putting more intelligence in the endpoints instead of in the
network). 

Thanks,
G.
> mainly
> > >> Further, there are two types of peers: peers with some SIP entity
> and
> > >> peers without any SIP entity.
> (only
> clients,
> agreement
> > minutes are at
> http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html).
> >

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 15 Nov 2007 11:35:52 -0500

> provide interconnection with other SIP networks.
Neither of the above requirement means many or all of the Peers must
be coupled with SIP Proxy entity.

> doesn't need to be routed through the overlay.
Right. The first SIP Proxy is on a Peer in this case.
I meant what you wrote but put it wrongly.

> to send a lookup if you are a client, isn't it?

Interesting point.
Location data can be signed by the callee easily. No Peer has right to
modify it.
SIP Proxy generally has right to modify SIP messages it forwards. (I
think Jonathan mentioned this in this mailing list some time ago.)
So concern on getting location data through another Peer is less than
having your SIP INVITE messages routed by another Peer's Proxy entity,
I think.

> are somehow putting more intelligence in the endpoints instead of in the

I am glad to know that I am not alone. :-)

Thanks.

Eunsoo

-- 
Eunsoo

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 15 Nov 2007 19:12:25 +0100

> peers, (b) clients, and (c) SIP UAs that attach via an proxy.

I think we should not mix P2P role (storage,routing) and SIP entities
when defining roles since a peer could be coupled with SIP UA.

From the P2P point of view, we could consider: (a) nodes offering
storage and routing -aka Peers- (b) nodes offering storage -aka
Clients- (c) consumers

Now, I suggest how I imagine mapping P2P roles and SIP entities:

Consumers: Very basic nodes -e.g. mobile phone- coupled with SIP UA.

Clients: Basic nodes offering storage capabilities. Information stored
in Clients will be only important information for Clients Session
-something like caching- (e.g where is my buddy connected from? who is
my bootstrap and admitting node today? I download my voicemails from
the overlay when I join the network, etc). Coupled with SIP UA. (e.g.
Computer). In case of Consumer, this 'caching information' would be
stored by it's responsible peer.

Peers: Advanced nodes providing routing and storage capabilities.
Information stored in peers could be 'how to locate a given user',
'given user key is X', 'given user buddy list is Y' allowing users to
register from different nodes. Coupled with NONE or ANY SIP entity.
(e.g. wireless mesh routers in WMNs hybrid topology, advanced AP,
switch, etc.)

Clients and consumers will reach P2PSIP overlay through peers. While
Clients will store some information, peers will store information on
behalf of consumers.

Consumers would NOT use clients to get registered since peers coupled
with SIP proxy would be used.

> I am still waiting for that agreement.

For sure we will do :-)

Thanks,

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 15 Nov 2007 10:39:24 -0800

Phil,

> but none of us are strong advocates of clients,

Wrong!

Some of us are strong advocates of clients.

Your earlier proposal was however very good:

* Describe a problem that you want to solve using clients.
* Present a convincing argument why that problem is interesting.
* Present a convincing argument why that problem cannot be solved using
peers.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 6:57 AM
To: P2PSIP Mailing List
Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior

Yup.

- Philip

---

From: Zheng Hewen <[email-masked]>
Date: Fri, 16 Nov 2007 14:44:16 +0800

Hi,

    Please see inline...

Best regards,
Hewen

> Sent: 2007?11?15? 20:49
> Cc: 'Eunsoo Shim'; 'Victor Pascual ??vila'; 'Henry
> Sinnreich'; 'P2PSIP Mailing List'
> > Further, there are two types of peers: peers with some SIP
> entity and
> > that there are mainly three types of nodes: peers (participating in
> > overlay, contributing storage capacity), clients (only contributing
> > storage capacity to their associated
> Right now, the reference model identifies three types of
> nodes: (a) peers, (b) clients, and (c) SIP UAs that attach
> via an proxy.
>

[Hewen] "Clients" and "SIP UAs" are nodes with SIP UA, the only difference between them is that clients attach peers WITHOUT
any SIP entity but "SIP UAs" attach peers WITH SIP entity (proxy/registrar), but I do agree with your opinion.

> > and essentially SIP usually is regarded one type of service over
> > P2PSIP overlay layer.
>
> This is not actually true. Right now, the concepts draft says
> that defines the client protocol as something OTHER than SIP,
> in order to distinguish (b) and (c) above.
>

[Hewen] Support to use clients to distinguish the attachment relations.

> > agreement about P2PSIP client character according to the Reference
> > model, any comment?
>
> Yes. Once we reach agreement on what a client should be, a
> number of sections in the Concepts draft will be to be rewritten.
>

[Hewen] Hope we can reach agreement in mail list or in Vancouver. I personally think that it is time to clarify P2PSIP
clients' characters. I do not see any doubt about the existence of P2PSIP clients in the mail list, any comment? Do you
think that the third alternative is rational when we think that P2PSIP clients are non-overlay-routing nodes in IETF69?

---

From: Zheng Hewen <[email-masked]>
Date: Fri, 16 Nov 2007 15:31:11 +0800

Hi,

   Great, essentially there are some nodes which are not eligible or willing to act as peers.
   From the viewpoint of P2PSIP overlay network stableness, it is very helpful when regarding those nodes frequently
joining/leaving overlay as P2PSIP clients.
   Further, it is more convenient to manage P2PSIP overlay network and provision services over the overlay network when
regarding nodes from some users as P2PSIP clients.
   We can have mobile peers, but we have more mobile clients, here is a practical example of P2PSIP in mobile communication,
please check the URL for the detailed info (http://www3.informatik.uni-wuerzburg.de/mp2p2007/slides/mp2p_5.pdf).

Best regards,
Hewen

> Sent: 2007?11?15? 23:21
> - A SIP UA node that is not a Peer must be attached to a Peer
> that is coupled to SIP Proxy entity. (please see the
> difference between 'node'
> and 'entity'.). In other words, to support SIP UA nodes to
> access the overlay, many (probably most) Peers should be
> coupled to SIP Proxy entities. It is an unnecessary
> requirement for Peers if we define Client node types.
> Furthermore, I'd prefer to use the overlay just for looking
> up the location of my callee rather than transport my INVITE
> messages through the overlay considering the a Proxy entity
> running on a Peer may not be so trustworthy. By removing the
> possibility of a node to be a Client coupled with SIP UA
> entity, we are enforcing any non-Peer SIP UA node to
> transport INVITE messages through Proxies running on Peers.
> - If we want other types of non-Peer nodes to be able to
> access the overlay, we will have to require Peers to
> implement other entities.
> Even though we want to focus on scenarios using SIP, we
> already agreed that it would be better to make the overlay
> generic enough to support non-SIP applications as long as the
> overlay can support SIP applications well. Here is a non-SIP
> application scenario where Client node type is useful. A
> mobile device that uses the overlay for asynchronous
> messaging or small file (eg. small resolution photos)
> sharing. None of the applications use SIP UA. Such mobile
> device would better be a Client than a Peer. Why would we
> want to prohibit this kind of application scenarios?
>
> Thanks.
>
> Eunsoo
>
> > Great minds think alike. Philip just posted a request for a
> draft on
> > client requirements.
> >
> > >> and peers without any SIP entity.
> nodes: (a)
> > We discussed the "clients contributing storage capacity" idea just
> > before the Prague IETF. I'm still not sure we have
> agreement on what
> > clients are (beyond "nodes that speak a logical subset of the peer
> > protocol"), and I'm pretty sure that we don't have agreement that
> > clients contribute storage capacity.
> >
> > Philip is correct here. The current version of the application
> > scenarios draft
> >
> (http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.t
> > xt) distinguishes between these cases as follows:
> >
> > (HINT: the application scenarios draft includes analysis
> about whether
> > each scenario seems to require "P2P Client Support" and/or
> > "Interoperation with CS-SIP" - I don't think any of the
> draft authors
> > are prejudiced against clients, but none of us are strong
> advocates of
> > clients, so it would be good to have client advocates
> develop opinions
> > about whether that analysis is reasonable or not)
> >
> > David and Brian asked me to lead discussion on clients in
> Prague (my
> > slides are at
> > http://www3.ietf.org/proceedings/07mar/slides/p2psip-6.pdf,
> meeting minutes are at
> > I'd summarize the sense of the room was in Prague as (1) at
> that time,
> > we did not have creditable use cases ("application scenarios") for
> > clients contributing storage apacity, and (2) we didn't
> have agreement
> > within the working group on what clients were.
> >
> > I don't believe the chairs tried to verify the sense of the room on
> > the mailing list after the meeting, so we can't say "the
> working group
> > has consensus" about these points, but that's the way things were
> > headed in the face-to-face meeting.
> >
> > Several people in the room at Prague raised their hands and
> said they
> > would discuss clients privately. Did that happen? If it
> did, we need to see text.

---

From: Zheng Hewen <[email-masked]>
Date: Fri, 16 Nov 2007 15:44:02 +0800

Hi,

    Please see inline...

Best regards,
Hewen

> Sent: 2007?11?16? 2:39
> To: Philip Matthews; P2PSIP Mailing List
> Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior
>
> Phil,
>

[Hewen] Support.

[Hewen] Agree.

> * Present a convincing argument why that problem cannot be
> solved using peers.
>

[Hewen] IMHO, it seems strange, Peers is stronger than clients in P2PSIP overlay network. Do you think that there is
something clients can do but peers can't? Those are some nodes which are not able and/or eligible to act as peers in fact.

> >  Philip: Those that want P2PSIP Clients need to come up
> with a good
> > use

---

From: Zheng Hewen <[email-masked]>
Date: Fri, 16 Nov 2007 18:04:23 +0800

Hi,

    Please see inline...

Best regards,
Hewen

> Sent: 2007?11?15? 22:57
> I agree. Right now, I think that most of the most active
> participants in the group are in the "Show me the money"
> camp. That is, we are not opposed to them, but we want to see
> a good argument for them.
>

[Hewen]We are only frank engineers. Sorry for the latest straight discussion if it caused some uncomfortable. I always think
that Concept document is a great work. Thanks for the hard efforts from the editors with my sincere respect.

> Some people have said "Mobile devices (e.g., handsets) cannot
> be peers for battery reasons or storage reasons or ...". But
> these are just words in the corridor, and not written down.
> And I keep hearing others say "Nonsense, we CAN have mobile peers".
>

[Hewen] It seems that a formal I-D about P2PSIP clients requirement/character is important and desired, is my understanding
correct?

> >  Philip: Why do we need P2PSIP clients?  The answer will
> drive whether
> > or  not we use them.
> >
> >  Philip: Those that want P2PSIP Clients need to come up with a good
> > use  case by Chicago IETF.  If they do not come up by then,
> the P2PSIP
> > Clients  go away. ]
> >
> > Hum - Should the wg work on the normal garden variety SIP
> UA connected
> > to
> >  Those that want a P2PSIP Client distinct from a normal SIP client
> > need to  get together and work on use cases. ]
> >
>
> Yup.
>
> - Philip
>

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 16 Nov 2007 13:32:30 -0600

If I have confused Henry and other people - in Philip's note that Henry 
replied to, the text was "but none of us are strong advocates of clients".

This was from MY earlier posting, on 15-Nov-07, at 08:23, where the context 
was

> develop opinions about whether that analysis is reasonable or not)

I was referring to the draft authors for a specific draft, not to the entire 
working group, or the entire P2P community :-)

What I meant by this was that the draft authors had gone through each 
application scenario, looking for the scenarios that seemed to require more 
users than peers, assuming that the way you support more users than peers is 
through SOME kind of client, either CS-SIP or "a client protocol", and 
trying to visualize whether CS-SIP would be sufficient in these scenarios, 
but none of the authors had expressed strong opinions about the need for a 
non-SIP client protocol during our work on the draft.

When this draft was submitted, none of us had written a draft advocating 
non-SIP clients, although Eunsoo said earlier this week that he will do 
that.

That's ALL I meant, and if people would like to express opinions about 
application scenarios in 
http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt, we 
would be thrilled to hear them.

Thanks,

Spencer

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 16 Nov 2007 14:04:41 -0800

It's OK and please don't worry about the difficulties of completely
clear mail communications. If anything, they only point to how more
difficult tight protocol specifications are :-)

Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 11:33 AM
To: P2PSIP Mailing List
Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior

If I have confused Henry and other people - in Philip's note that Henry 
replied to, the text was "but none of us are strong advocates of
clients".

This was from MY earlier posting, on 15-Nov-07, at 08:23, where the
context 
was

> develop opinions about whether that analysis is reasonable or not)

I was referring to the draft authors for a specific draft, not to the
entire 
working group, or the entire P2P community :-)

What I meant by this was that the draft authors had gone through each 
application scenario, looking for the scenarios that seemed to require
more 
users than peers, assuming that the way you support more users than
peers is 
through SOME kind of client, either CS-SIP or "a client protocol", and 
trying to visualize whether CS-SIP would be sufficient in these
scenarios, 
but none of the authors had expressed strong opinions about the need for
a 
non-SIP client protocol during our work on the draft.

That's ALL I meant, and if people would like to express opinions about 
application scenarios in 
http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt,
we 
would be thrilled to hear them.

Thanks,

Spencer

---

From: Philip Matthews <[email-masked]>
Date: Sat, 17 Nov 2007 11:55:31 -0500

>
> [Hewen] Hope we can reach agreement in mail list or in Vancouver. I  
> personally think that it is time to clarify P2PSIP
> clients' characters. I do not see any doubt about the existence of  
> P2PSIP clients in the mail list, any comment?

Before the working group was formed, there were various people  
talking about ideas related to P2PSIP. Hence the Concepts draft was  
originally written to unite these various groups around a rough  
vision of what we wanted to do. Some of the people wanted clients,  
while others didn't see the need for them. Hence the concept of  
clients was put into the Concepts draft, but with a note that they  
may or may not exist.

Various ideas for what a client might be have put forth, and have  
been documented in the Concept draft. However, what has always been  
lacking is a strong argument for why we cannot just have peers. Hence  
the request in Prague for an I-D that would put forth this argument,  
and hence my repeat of this request on the mailing list a few days ago.

> [Hewen] Do you think that there is
> something clients can do but peers can't? Those are some nodes  
> which are not able and/or eligible to act as peers in fact.

Why are clients not able to act as peers? Is there a technical  
reason, or some other reason? Some people have suggested that they  
might not have enough processing capability or battery life, but we  
don't yet know what processing capability or battery life a peer will  
need. Are their strong technical reasons why we won't be able to  
design a peer protocol that will run on devices such as this?

If a strong argument can be made that any reasonable peer protocol  
design could not run on a certain class of devices, then this would  
be a good argument for clients. However, just saying "It cannot be  
done" is not sufficient.

- Philip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Nov 2007 12:06:40 -0500

> don't yet know what processing capability or battery life a peer  
> will need. Are their strong technical reasons why we won't be able  
> to design a peer protocol that will run on devices such as this?
>

For typical DHTs, the bandwidth needs are dramatically higher for  
peers than for clients, at least for all the DHTs that we are  
currently considering. Simple calculation: For a 1000 node DHT,  
roughly 1% of all queries will traverse any given peer, i.e., one in a  
hundred calls. For a busy network, that could be tens to hundreds of  
calls a second. That's a lot of network activity for a battery- 
operated node - or one that pays for bandwidth by the byte. Thus, it  
doesn't matter how high the absolute cost, as there will be networks  
where 1% of the calls exceeds the capacity of mobile nodes.

Clients can go off-line, which happens fairly frequently for wireless  
devices; peers shouldn't (unless you like to deal with lots of churn,  
which then requires much higher replication).

> be a good argument for clients. However, just saying "It cannot be  

Your raising the bar to the impossible. You can never prove that  
something cannot be done; for all we know, we can exceed the speed of  
light. We do know what can and cannot be done with current DHT  
algorithm proposals. For those, I see clients as necessary and easy to  
support.

Frankly, I don't understand your reluctance to deal with clients. All  
protocol proposals trivially accommodate them, as far as I can tell,  
so it's not like this is going to cause dramatic scope creep.

Let me turn this around. I'd like to hear from people who have an  
argument as to why clients are not needed or why they cause  
significant increases in complexity.

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 19 Nov 2007 10:08:28 +0800

Hi,

    Please see inline... ...

Best regards,
Hewen

> Sent: 2007?11?18? 0:56
> > personally think that it is time to clarify P2PSIP clients'
> > characters. I do not see any doubt about the existence of P2PSIP
> > clients in the mail list, any comment?
>
> Before the working group was formed, there were various
> people talking about ideas related to P2PSIP. Hence the
> Concepts draft was originally written to unite these various
> groups around a rough vision of what we wanted to do. Some of
> the people wanted clients, while others didn't see the need
> for them. Hence the concept of clients was put into the
> Concepts draft, but with a note that they may or may not exist.
>
> Various ideas for what a client might be have put forth, and
> have been documented in the Concept draft. However, what has
> always been lacking is a strong argument for why we cannot
> just have peers. Hence the request in Prague for an I-D that
> would put forth this argument, and hence my repeat of this
> request on the mailing list a few days ago.
>
[Hewen]Thanks for your information, agree with you that such an I-D is desirable.

> > something clients can do but peers can't? Those are some
> nodes which
> > are not able and/or eligible to act as peers in fact.
>
> Why are clients not able to act as peers? Is there a
> technical reason, or some other reason? Some people have
> suggested that they might not have enough processing
> capability or battery life, but we don't yet know what
> processing capability or battery life a peer will need. Are
> their strong technical reasons why we won't be able to design
> a peer protocol that will run on devices such as this?
>
> If a strong argument can be made that any reasonable peer
> protocol design could not run on a certain class of devices,
> then this would be a good argument for clients. However, just
> saying "It cannot be done" is not sufficient.
>
[Hewen]Oh, frankly, it is a very smart question. Nobody can prove that something is impossible; can I say "the reason is
Nothing Is Impossible"? Essentially, we potentially have some predetermined assumption in P2PSIP, for example, as one
discussion in the mail list, we already assume that peers have infinite storage capacity, what happens on those nodes with
limited storage capacity or without contributable storage capacity? Those nodes should not act as peers according to our
assumption, but those nodes wants P2PSIP service though those nodes only have thin storage capacity, what then will those
nodes be? Peer? No. Those nodes will be clients. We seldom see some technical reason about why P2PSIP clients do not exist.
We need to face the existence of clients and clarify clients character/behaviors even when a thin peer protocol or
unmodified SIP is enough to act as the communication protocol between peers and clients, this work will be very helpful to
P2PSIP deployment in real world. Would someone tell us why clients can or shall not exist in P2PSIP?

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 19 Nov 2007 10:13:10 +0800

Hi,

    Please see inline... ...

Best regards,
Hewen

> Sent: 2007?11?18? 1:07
> To: Philip Matthews
> technical reason,
> > or some other reason? Some people have suggested that they
> might not
> > have enough processing capability or battery life, but we don't yet
> > know what processing capability or battery life a peer will
> need. Are
> > their strong technical reasons why we won't be able to
> design a peer
> > protocol that will run on devices such as this?
> >
>
> For typical DHTs, the bandwidth needs are dramatically higher
> for peers than for clients, at least for all the DHTs that we
> are currently considering. Simple calculation: For a 1000
> node DHT, roughly 1% of all queries will traverse any given
> peer, i.e., one in a hundred calls. For a busy network, that
> could be tens to hundreds of calls a second. That's a lot of
> network activity for a battery- operated node - or one that
> pays for bandwidth by the byte. Thus, it doesn't matter how
> high the absolute cost, as there will be networks where 1% of
> the calls exceeds the capacity of mobile nodes.
>
> Clients can go off-line, which happens fairly frequently for
> wireless devices; peers shouldn't (unless you like to deal
> with lots of churn, which then requires much higher replication).
>

[Hewen] Support. It is very real.

> > design could not run on a certain class of devices, then
> this would be
> > a good argument for clients. However, just saying "It
> cannot be done"
> > is not sufficient.
>
> Your raising the bar to the impossible. You can never prove
> that something cannot be done; for all we know, we can exceed
> the speed of light. We do know what can and cannot be done
> with current DHT algorithm proposals. For those, I see
> clients as necessary and easy to support.
>
> Frankly, I don't understand your reluctance to deal with
> clients. All protocol proposals trivially accommodate them,
> as far as I can tell, so it's not like this is going to cause
> dramatic scope creep.
>
> Let me turn this around. I'd like to hear from people who
> have an argument as to why clients are not needed or why they
> cause significant increases in complexity.
>
[Hewen] I have no more words, just "Agree". As your said, nobody tell us "why clients are not needed or why they cause
significant increases in complexity".

---

From: Philip Matthews <[email-masked]>
Date: Mon, 19 Nov 2007 08:41:47 -0500

On 17-Nov-07, at 12:06 , Henning Schulzrinne wrote:

>
> Frankly, I don't understand your reluctance to deal with clients.  
> All protocol proposals trivially accommodate them, as far as I can  
> tell, so it's not like this is going to cause dramatic scope creep.
>

1) The usual desire not to introduce a concept that is not needed.
2) No clear idea why people want clients. So far, the only agreed- 
upon description of a client is that they do something less than a peer.
3) No clear description of what a client is. Concepts-01 lists three  
different alternatives that have been proposed by people, and so far  
there seems to be no WG consensus around any of these.

Your e-mail is a good start to an argument why there might be nodes  
that can and might want to be clients, but cannot be peers, though it  
still doesn't describe WHAT a client is.

Let me be clear. Given a good argument, I am quite willing to have  
the concept of a client. I just need to know what it is and why I  
need it.

- Philip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Nov 2007 08:43:06 -0500

> that can and might want to be clients, but cannot be peers, though  
> it still doesn't describe WHAT a client is.

That's simple: For the current definition of the protocols, P2PSIP  
protocols do a key-to-value lookup. A client can perform a get and put  
operation (and other related data manipulation operations), but does  
not route P2PSIP protocol requests.

Henning

---

From: Philip Matthews <[email-masked]>
Date: Mon, 19 Nov 2007 08:52:11 -0500

On 19-Nov-07, at 08:43 , Henning Schulzrinne wrote:

>>
>> Your e-mail is a good start to an argument why there might be  
>> nodes that can and might want to be clients, but cannot be peers,  
>> though it still doesn't describe WHAT a client is.
>
> protocols do a key-to-value lookup. A client can perform a get and  
> put operation (and other related data manipulation operations), but  
> does not route P2PSIP protocol requests.
>

Write it up in short I-D!

Seriously: having a clear description written down in an I-D with  
good arguments for why this is interesting and why there are nodes  
that can do this but cannot be a peer would be immensely helpful to  
the WG.

- Philip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Nov 2007 13:33:09 -0800

> does not route P2PSIP protocol requests.

I would probably add that it does not store information that is saved  
in the DHT. (i.e. other nodes can not sent a PUT or GET to the  
client, clearly the client and PUT some information into the DHT by  
sending a PUT to another node).

One of the interesting questions about Clients to me is if a given  
overlay allows Clients to connect, what is the incentive for anyone  
to be a Peer. I'm not sure we will ever come to a good answer to this  
other than to deploy and see.

Cullen <with my individual hat on>

---

From: Dean Willis <[email-masked]>
Date: Mon, 19 Nov 2007 15:57:31 -0600

> does not route P2PSIP protocol requests.

Does a client store stuff for other users in the overlay? If not,  
that's another difference between clients and peers.

Personally, I'm now thinking of "client" and "peer" nodes as  
hypothetical points in a continuum of functionality. I expect real  
systems to slide around in that continuum based on their current  
circumstances. They might be high bandwidth or low bandwidth, plugged  
in or battery operated, charged by byte or all-you-can-eat, have no  
free memory or terabytes of it, be stuck behind an obnoxious firewall  
or full-exposed. They might be very busy, or operating with no load  
at all. They might have STUN capacity to offer, and they might not.  
There are probably more axes of freedom in this continuum than we  
have yet imagined.

And many devices will shift where the are, from time to time. Mobile  
devices will move between access points and access technologies.  
Devices in data centers will get busy. Voice mail boxes will fill up.  
Any device might be affected by maintenance, peripheral death, and so  
on.

So I'd really like to see some way that nodes can adapt to their  
changing situations without having to make an all-or-nothing  
commitment. Even for nodes that are "fully committed", I'd like to se  
a way for them to back off gracefully so they're not "fully  
committed" the same way a goose is to foie gras -- that is, stuffed  
beyond capacity and then turned into pate'.

--
Dean

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 19 Nov 2007 20:40:17 -0500 (EST)

is available at:
http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-01.txt

    This document defines the Peer-to-Peer Protocol (P2PP), an
    application-layer binary protocol, for creating and maintaining an
    overlay of participant nodes.  The overlay can be created using
    various structured and unstructured peer-to-peer protocols such as
    Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a
    secure transport, supports an application API, has mechanisms for NAT
    and firewall traversal, exchanging node capabilities, and diagnostic
    information.  P2PP is designed to support a P2P Session Initiation
    Protocol (SIP) network, but it can be used for other applications as
    well.

Comments are welcome.

-salman

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 20 Nov 2007 10:18:46 +0800

Hi,

    In my understanding, P2PSIP client is a node which gets P2PSIP overlay services (e.g., distributed storage and
distributed transport) from an associated P2PSIP peer without any SIP entity. P2PSIP clients are non-overlay-routing nodes,
and P2PSIP peers are overlay-routing nodes, P2PSIP overlay network is transparent to P2PSIP clients (i.e. P2PSIP clients are
not aware of the topology of P2PSIP overlay network).
   Some nodes acts as P2PSIP clients due to limited capability (e.g., limited power/lifetime, thin storage capacity), some
nodes acts as P2PSIP clients due to considering the performance and burden of P2PSIP network (e.g., more peers mean that
more P2PSIP traffic consume rare and costly bandwidth of mobile nodes and potentially bigger delay), some nodes acts as
P2PSIP clients due to considering the security and management (e.g., P2PSIP communication network deployed in an autonomous
environment such as enterprises' VPN), We will detail the use cases about P2PSIP clients in an new I-D.
   For your question, P2PSIP clients can contribute its storage capacity to earn encouragement points, which can be regarded
as one incentive mechanism. Essentially, in some scenarios (e.g., in an autonomous P2PSIP communication network), such an
incentive mechanism is not necessary.
   But here is one issue about the merged RELOAD-01, if P2PSIP clients own Peer-ID, will this violate DHT algorithm when
P2PSIP clients never are used to store any DHT data? Will the namespace of P2PSIP overlay not be fully available for peers?
Personally, I do not think that it will impact the other P2PSIP clients application scenarios, but I wonder the answers for
those above questions. Certainly, if P2PSIP clients use the other namespace than P2PSIP peers, then all is OK.

Best regards,
Hewen

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: 2007?11?20? 5:33
> To: Henning Schulzrinne
> Cc: Philip Matthews; P2PSIP Mailing List
> I would probably add that it does not store information that
> is saved in the DHT. (i.e. other nodes can not sent a PUT or
> GET to the client, clearly the client and PUT some
> information into the DHT by sending a PUT to another node).
>
> One of the interesting questions about Clients to me is if a
> given overlay allows Clients to connect, what is the
> incentive for anyone to be a Peer. I'm not sure we will ever
> come to a good answer to this other than to deploy and see.
>

---

From: JiangXingFeng <[email-masked]>
Date: Tue, 20 Nov 2007 10:31:27 +0800

Another case where acting as a client may be better than acting as a peer
for a node. 

In some cases, there are some nodes providing services which are useful to
the overlay, for example, STUN, TURN service, etc. If these nodes are put
into the overlay as a peer, it should participate in the overlay maintenance
work, store <key, value> pair on behalf the overlay and forward the packet
for other peers. These works will account for part of resource they have.
Moreover, if these nodes play Peer role in addition to service provider, it
may be under the threats which comes from its peer role.  So from the
stability of the provided service, the best role they play may be clients,
not peer, even they have strong processing power, high bandwidth, on the
public Internet, etc.

Regards!
--
Jiang XingFeng

> Sent: Monday, November 19, 2007 9:43 PM
> To: Philip Matthews
> Cc: P2PSIP Mailing List

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Nov 2007 21:12:23 -0800

On Nov 19, 2007, at 6:18 PM, Zheng Hewen wrote:

>  But here is one issue about the merged RELOAD-01, if P2PSIP  
> clients own Peer-ID, will this violate DHT algorithm when
> P2PSIP clients never are used to store any DHT data? Will the  
> namespace of P2PSIP overlay not be fully available for peers?
> Personally, I do not think that it will impact the other P2PSIP  
> clients application scenarios, but I wonder the answers for
> those above questions. Certainly, if P2PSIP clients use the other  
> namespace than P2PSIP peers, then all is OK.

Let's say some peer-id, X is being used by a client. From the  
perspective of the the peers for routing and storage, this is the  
same as if  X had been allocated to some peer but that peer was not  
currently online. The client never does a join to insert X into the  
DHT topology. The whole space of resource-id is still available for  
use by the DHT. The advantage of this design is that unifies the  
authorization model for clients and peer.

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 20 Nov 2007 13:54:20 +0800

Hi,

   Please see inline ... ...

Best regards,
Hewen

> Sent: 2007?11?20? 13:12
> Subject: Re: [P2PSIP:Survey] P2PSIP Client Character/Behavior
>
>
> >  But here is one issue about the merged RELOAD-01, if
> P2PSIP clients
> > own Peer-ID, will this violate DHT algorithm when P2PSIP
> clients never
> > are used to store any DHT data? Will the namespace of
> P2PSIP overlay
> > not be fully available for peers?
> > clients application scenarios, but I wonder the answers for those
> > above questions. Certainly, if P2PSIP clients use the other
> namespace
> perspective of the the peers for routing and storage, this is
> the same as if  X had been allocated to some peer but that
> peer was not currently online. The client never does a join
> to insert X into the DHT topology. The whole space of
> resource-id is still available for use by the DHT. The
> advantage of this design is that unifies the authorization
> model for clients and peer.
>

[Hewen] In my understanding to your description above, the "Peer-IDs" of P2PSIP clients never emerge in DHT topology of
P2PSIP overlay network, the design of RELOAD-01 only use them to identify clients and reuse the authorization model which
already is used in enrollment or peers' joining procedure. Further, the "Peer-IDs" above are in fact some type of
identifiers of P2PSIP clients, some peers in P2PSIP overlay network can use "Peer-IDs" which have the same value with
"Peer-IDs" owned by P2PSIP clients because those "Peer-IDs" of P2PSIP clients never appear in the overlay network (i.e.,
Node-IDs never conflict due to repeat). In summary, essentially, the "Peer-IDs" of P2PSIP clients sit in the completely
different and separate namespace with "Peer-IDs" of P2PSIP peers, is my understanding correct?

---

From: "lichun li" <[email-masked]>
Date: Tue, 20 Nov 2007 14:07:51 +0800

Agree. We also analyze the necessity of P2PSIP Client. IMHO, P2PSIP Client
is needed in four kinds of cases
as described in "
http://tools.ietf.org/wg/p2psip/draft-li-p2psip-client-protocol-00.txt".
One kind of cases is usually overlooked:
   "Firstly, the heterogeneity of P2P overlays makes P2PSIP Client
   necessary.  For example, a P2PSIP node which only supports Chord
   algorithm, needs to access services of P2PSIP overlay which uses
   Bamboo as P2P algorithm.  Due to the incompatible P2P algorithms, the
   Chord-based node can not join in the Bamboo-based DHT overlay.  Thus
   the Chord-based node has to work as P2PSIP Client."

-- 
Sincerely yours,

Lichun Li

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Nov 2007 23:49:54 -0800

On Nov 19, 2007, at 9:54 PM, Zheng Hewen wrote:

> [Hewen] In my understanding to your description above, the "Peer- 
> IDs" of P2PSIP clients never emerge in DHT topology of
> P2PSIP overlay network, the design of RELOAD-01 only use them to  
> identify clients and reuse the authorization model which
> already is used in enrollment or peers' joining procedure. Further,  
> the "Peer-IDs" above are in fact some type of
> identifiers of P2PSIP clients, some peers in P2PSIP overlay network  
> can use "Peer-IDs" which have the same value with
> "Peer-IDs" owned by P2PSIP clients because those "Peer-IDs" of  
> P2PSIP clients never appear in the overlay network (i.e.,
> Node-IDs never conflict due to repeat). In summary, essentially,  
> the "Peer-IDs" of P2PSIP clients sit in the completely

It is mostly correct. The place where a client's peer-id would be  
look at in the DHT was if there was a usage where some data type  
needed to be signed by the peer-id. If the client signed with their  
peer-id, some peer in the DHT may end up checking that signature. So  
you would not the enrollment process to assign the same peer-id to a  
client and also to a peer that were not associated with the same  
user. There could also be some confusion  if a peer with ID X  
directly connected to peer with id Y and Y was also directly  
connected to a client with peer X.

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 20 Nov 2007 09:25:29 +0100

> not peer, even they have strong processing power, high bandwidth, on the

I fully agree.
Peers (overlay) would be used to locate services and Clients would
implement these services. Thus, new services introduction would be
easier, scalable and we should not modify the overlay every time a new
service is introduced.
Using Service Oriented Architecture (SOA), Peers could be considered
as 'Service Providers' and Clients as 'Service implementors'.

Thanks,

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 20 Nov 2007 06:29:00 -0500

On Nov 20, 2007 3:25 AM, Victor Pascual Ávila
<[email-masked]> wrote:
> implement these services.

This is too general a statement.
It is true that a Client may implement/provide a service.
But same for a Peer.
Whether a node becomes a Peer or a Client is independent of whether it
provides a particular service other than routing of overlay messages
and maintaining the overlay.

Thus, new services introduction would be

Thanks.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 20 Nov 2007 06:32:42 -0500

> different and separate namespace with "Peer-IDs" of P2PSIP peers, is my understanding correct?

I don't know the intention of the RELOAD draft authors.
But I have been thinking that a Client gets a Node ID as a Peer does.
In my picture, there is no difference between the Node ID assigned to
a Peer and Node ID assigned to a Client.
You have only one Node ID space.
If an ID is taken, the ID is used. The ID won't be assigned (should
not be assigned) to any node regardless of the node type.

Thanks.
-- 
Eunsoo

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 20 Nov 2007 13:13:59 +0100

> and maintaining the overlay.

[vp] Then, clients are non-overlay-routing nodes and at the same time
they contribute their storage capacity _and/or_ their -specialized
resource consuming- services (e.g mixing server) to P2PSIP overlay
network.

Thank you,

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 15:37:21 +0200

Hi all,

I agree with Eunsoo. The client protocol must support PUT, GET, JOIN and
Bootstrap methods. Clients do not need to store any data on behalf of
other P2PSIP nodes (but they may decide otherwise). The client discovers
services and users' location and publishes its own information in the
overlay using a client protocol. When a SIP UA is collocated with a
client software the client requests an IP address and port of callee and
establishes a SIP session directly (or through a relay) to the other
end. Client don't need to implement a SIP stack. It can be a node that
advertises non-SIP services to the overlay e.g. media relaying services.

Definitely the client protocol can be a subset of a peer protocol as it
is shown in the P2PP draft.

Marcin      

>From: ext Eunsoo Shim [mailto:[email-masked]] 
>Sent: 14 November, 2007 17:22
>To: Yao Wang
>Cc: P2PSIP Mailing List; Henry Sinnreich; Philip Matthews
>The overlay needs to provide just distributed database 
>functionality (== distributed storage and search/lookup 
>functionality) and at most some kind of generic 
>transport/routing functionality. These functionalities can be 
>well summarized as PUT, GET, and SEND functions.
>
>Any information about SIP related services such as mapping of 
>SIP URI to a location(IP address) or nodes providing certain 
>application functions/services like conferencing server can be 
>stored and looked up using the Peer (and Client) Protocol. You 
>don't need SIP at all here.
>
>That is the idea accepted by the group widely. Now all the 
>proposals about Peer Protocol do not use extensions/variations of SIP.
>
>If we all understand that Client Protocol provides only a 
>subset of Peer Protocol's functionality and Peer Protocol can 
>be and better be implemented independently of SIP, why would 
>we need to have SIP for Client Protocol? It does not make sense to me.
>
>Thanks.
>
>Eunsoo
>
>> Currently, the main difference in the debate comes from how 
>to build the client protocol, whether it could be based on 
>SIP, whether it could be a syntax subset of Peer Protocol, or 
>whether it is a separate protocol different from both SIP and 
>Peer Protocol but its function is subset of the functions of 
>Peer Protocol.
>>
>>         Firstly, from the charter of this WG, this WG "is 
>chartered to develop protocols and mechanisms for the use of 
>the Session Initiation Protocol (SIP)". It is clearly that SIP 
>service (including locating target user, forwarding SIP 
>messages) is a basic service that P2PSIP Overlay MUST provide. 
>Client Protocol MUST enable client to access this services.
>>         Secondly, services other than SIP. As mentioned in 
>concept draft, some individual peers may provide services in 
>addition to storage and routing, for example STUN services, to 
>the overlay. However, because clients do not join P2PSIP 
>Overlay, they can not discover these services directly. 
>Therefore, client protocol MUST provide a mean for client to 
>know what services are available in the P2PSIP Overlay and the 
>comprehensive parameters for access these services. After 
>getting these parameters, the client can use other protocols, 
>for example STUN, to access the service, which should be out 
>of the scope of client protocol.
> When it comes to the second kind of requirements, both SIP 
>and other protocol (e.g. a subset of peer protocol) can work.
>>         If the subset of peer protocol is adopted as client 
>protocol (supposing the peer protocol is not SIP-based), the 
>client _has_  _to_ run two protocol stacks at the same time, 
>which obviously consumes more resources of client than only 
>running SIP stack. Given the assumption that clients are 
>resource-limited devices, running one more protocol stack may 
>cause the degradation of its performances.
>>         Thus, why not use SIP and SIP extensions to satisfy 
>both requirements? why not kill two birds with one stone?  
>Currently, many mobile devices have been equipped with SIP; 
>the reuse of SIP in client protocol not only reduces the 
>resource needed on client devices but also reduces the 
>implementation complexity of client protocol.
>>
>>         It seems that people in this list accept that the 
>client should contribute its storage capacity to peers. In my 
>opinion, the client can provide more service than that. Here 
>is one possible example which is described in our proposed 
>draft ("A SIP-based P2PSIP Client Protocol")
>>         "For example, a conferences server wants to provide 
>conference services to nodes in a P2PSIP system.  Because the 
>decoding, mixture and encoding of multiple media streams can 
>be quite a heavy load for its computational resources, this 
>conference server may choose not to join in the P2PSIP 
>overlay. Thus, some extra    resources, which would be used 
>for the maintenance of P2P overlay if the server joined 
>overlay, can be utilized for providing better conference services."
>>         Therefore, the client protocol must be extensible 
>for supporting any possible services. SIP is a well-developed 
>extensible signal protocol, thus, we propose to build client 
>protocol based on SIP.
>>
>> Any comments?
>>
>>
>> Sincerely yours,
>>
>> Yao Wang
>> modify the discussion on Clients in the draft.  It is not 
>that I don't 
>> want to do this, it is just that I think there is no 
>consensus yet on 
>> the nature or even existence of clients.
>>

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 15:59:26 +0200

Hi Philip and all,

>And I keep hearing others say "Nonsense, we CAN have mobile peers".

Both are true. Everything depends on a deployment scenario. Some mobiles
are quite static, some frequently change an access network, some mobiles
are behind a firewall and nat others have a public IP, some users pay
flat rate charges some don't, some mobiles are not enough powerful to
become a peer but some have enough fast CPU, large memory, etc..

I am against writing a draft describing all of the possibilities, this
group produced enough documents that none reads (but if it is required I
can allocate some time to write such as a draft but I need a reason why
do you need this) Do you think that we want to waste out time
standardizing a client protocol that we think is useless?

Marcin 

>From: ext Philip Matthews [mailto:[email-masked]] 
>Sent: 15 November, 2007 16:57
>To: P2PSIP Mailing List
>participants in the group are in the "Show me the money" camp. 
>That is, we are not opposed to them, but we want to see a good 
>argument for them.
>
>> Hum - Should the wg work on the normal garden variety SIP UA 
>connected 
>> to

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 20 Nov 2007 10:44:44 -0500

<as individual>
There are some good ideas here.  What if the protocol could adapt based on
measurement metrics, to bandwidth, computer power, and storage capability
variations?  A poorly connected device might store some data and do some
routing, but only for very "local" peers, for example.

It's likely subject to abuse, but it might work pretty well as long as most
implementations followed the rules.  Any implementation of clients has that
problem.

Brian

> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, November 19, 2007 4:58 PM
> To: Henning Schulzrinne
> Subject: [P2PSIP] Why just "peer" and "client"? (was Re: P2PSIP
> ClientCharacter/Behavior)
> 
>

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 18:20:13 +0200

Hi all,

Together with the University of Oulu we implemented the P2PP protocol on
the S60 platform. The P2PP is designed to work both on PCs and mobile
phones. The current implementation allows mobile phones to act both as
P2PSIP peers and P2PSIP clients. The demo of P2PP on Nokia phones will
be presented at CCNC in Las Vegas in January 2008. Everyone is welcome
to visit our stand!

If you are interested in P2P for handheld devices you may consider
visiting the P2PHD workshop:
http://cms.comsoc.org/CCNC_2008/Content/Home/Call_for_Papers_/P2P_HD_Wor
kshop.html  

You may find a link to the second version of the P2PP draft below.

Marcin  

>From: ext Salman Abdul Baset [mailto:[email-masked]] 
>Sent: 20 November, 2007 03:40
>To: P2PSIP Mailing List
>Subject: [P2PSIP] P2PP-01
>
>
>is available at:

---

From: Ingmar Baumgart <[email-masked]>
Date: Tue, 20 Nov 2007 18:50:23 +0100

Hi,

this sounds really interesting. Is the implementation open-source? And
what overlay protocols are currently implemented?

Regards,
  Ingmar

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Nov 2007 11:23:32 -0800

On Nov 20, 2007, at 3:32 AM, Eunsoo Shim wrote:

>> already is used in enrollment or peers' joining procedure.  
>> Further, the "Peer-IDs" above are in fact some type of
>> identifiers of P2PSIP clients, some peers in P2PSIP overlay  
>> network can use "Peer-IDs" which have the same value with

Yes - that is how RELOAD is. I think we occasionally get into a bit  
of confused about what we mean when we say and id is "used". I tried  
to separate that out a bit in my original email because, as Mr. Hewen  
is pointing out, they can be used many ways.

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 21 Nov 2007 10:04:52 +0800

> and maintaining the overlay.
I agree with you that the role of peers or clients is independent of the
services what they intends to provide. What I really suggest is that if a
node wants to provide service, acting as a client may be better than acting
as peer, so that it could avoid the influence from the overlay. This is a
reason why we need a client. 

Regards!

JiangXingFeng

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 21 Nov 2007 14:52:02 +0800

Hi,

   Please see inline... ...

Best regards,
Hewen

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 2007?11?20? 21:37
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> I agree with Eunsoo. The client protocol must support PUT,
> GET, JOIN and Bootstrap methods. Clients do not need to store
> any data on behalf of other P2PSIP nodes (but they may decide
> otherwise). The client discovers services and users' location
> and publishes its own information in the overlay using a
> client protocol. When a SIP UA is collocated with a client
> software the client requests an IP address and port of callee
> and establishes a SIP session directly (or through a relay)
> to the other end. Client don't need to implement a SIP stack.
> It can be a node that advertises non-SIP services to the
> overlay e.g. media relaying services.
>
[Hewen] Agree. The client protocol is a light-weight protocol, a P2PSIP client may contribute its storage capacity to its
associated peer or provide services to overlay network and publish the discovered services info into the overlay through its
associated peer.

> Definitely the client protocol can be a subset of a peer
> protocol as it is shown in the P2PP draft.
>
> Marcin
>
> >(== distributed storage and search/lookup
> >functionality) and at most some kind of generic transport/routing
> >functionality. These functionalities can be well summarized as PUT,
> >GET, and SEND functions.
> >
> >functions/services like conferencing server can be stored
> and looked up
> >using the Peer (and Client) Protocol. You don't need SIP at all here.
> >
> SIP, whether
> >it could be a syntax subset of Peer Protocol, or whether it is a
> >separate protocol different from both SIP and Peer Protocol but its
> >function is subset of the functions of Peer Protocol.
> >>
> >chartered to develop protocols and mechanisms for the use of the
> >Session Initiation Protocol (SIP)". It is clearly that SIP service
> >(including locating target user, forwarding SIP
> addition
> >to storage and routing, for example STUN services, to the overlay.
> >However, because clients do not join P2PSIP Overlay, they can not
> >discover these services directly.
> know what
> >services are available in the P2PSIP Overlay and the comprehensive
> >parameters for access these services. After getting these
> parameters,
> >the client can use other protocols, for example STUN, to access the
> >service, which should be out of the scope of client protocol.
> and other
> >protocol (supposing the peer protocol is not SIP-based), the client
> >_has_  _to_ run two protocol stacks at the same time, which
> obviously
> >consumes more resources of client than only running SIP stack. Given
> >the assumption that clients are resource-limited devices,
> running one
> >more protocol stack may cause the degradation of its performances.
> the reuse
> >of SIP in client protocol not only reduces the resource needed on
> >client devices but also reduces the implementation
> complexity of client
> >protocol.
> >>
> >client should contribute its storage capacity to peers. In
> my opinion,
> >the client can provide more service than that. Here is one possible
> >example which is described in our proposed draft ("A
> SIP-based P2PSIP
> >Client Protocol")
> >conference services to nodes in a P2PSIP system.  Because
> the decoding,
> >mixture and encoding of multiple media streams can be quite a heavy
> >load for its computational resources, this conference server
> may choose
> >not to join in the P2PSIP
> overlay, can be
> >utilized for providing better conference services."
> >based on SIP.

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 21 Nov 2007 10:39:00 -0500

> reason why we need a client.

To me, this argument seems completely backward from what I think makes
sense for a client. The only good reason for a client I've heard is
that it has some limited capacity and/or bandwidth. If the capacity or
bandwidth is limited, it seems it would *not* be a good choice to
offer services.

Why would being in the overlay be a bad influence?

Personally, I really don't like the direction this is going, if we say
that offering a service is a good reason not to be a peer. One of the
biggest problems with P2P is everyone wanting to be a client and not
participate in the overlay. If a device has enough bandwidth or power
to offer services, then it *definitely* should be a peer. The more
reasons we allow to cause a node to be a client rather than a peer,
the less peers, which means those need to be very powerful, and it
will be painful to be one, so they will want to be clients, so there
will be less peers....it spirals.

If it can possibly be a peer, I think it should be...

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 21 Nov 2007 10:42:04 -0500

> If it can possibly be a peer, I think it should be...

Yes.

-- 
Eunsoo

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 21 Nov 2007 11:40:34 -0800

A. Client Rationale
===================

> Why would being in the overlay be a bad influence?

A mobile client is more likely to change its IP address and thus force a
new stabilization process (Chord terminology) every time in the overlay.

B. Who Can Be A Peer
====================
> The more reasons we allow to cause a node to be a client rather than a

> peer 

Which nodes can declare themselves a peer and which are (mobile) clients
is a matter of policy by the overlay operator.

The nodes that can declare themselves a peer, within policy, will need
to meet certain criteria such as:

- Some security checks (which is TBD)
- NAT traversal scenario says it's behind no NAT or p2p-friendly NAT
- BW as seen by the node.

This topic (B.) deserves a memo written by a design team with input from
looking first at the existing p2p networks; and there are plenty of
them.

My two cents, 

Henry

-----Original Message-----
From: David A. Bryan [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2007 9:39 AM
To: JiangXingFeng
Cc: Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "lichun li" <[email-masked]>
Date: Thu, 22 Nov 2007 09:02:10 +0800

> bandwidth is limited, it seems it would *not* be a good choice to

I think there is another good reason: a node doesn't support the DHT
algorithm used in overlay.

> If it can possibly be a peer, I think it should be...

I agree. But there might be some exceptions.

David (as individual)

-- 
Sincerely yours,

Lichun Li

---

From: Zheng Hewen <[email-masked]>
Date: Thu, 22 Nov 2007 09:33:40 +0800

Hi,

Best regards,
Hewen

> Sent: 2007?11?21? 23:39
> > > Whether a node becomes a Peer or a Client is independent
> of whether
> > > it provides a particular service other than routing of overlay
> > > messages and maintaining the overlay.
> > I agree with you that the role of peers or clients is
> independent of
> > the services what they intends to provide. What I really suggest is
> > that if a node wants to provide service, acting as a client may be
> > better than acting as peer, so that it could avoid the
> influence from
> > the overlay. This is a reason why we need a client.
>
> To me, this argument seems completely backward from what I
> think makes sense for a client. The only good reason for a
> client I've heard is that it has some limited capacity and/or
> bandwidth. If the capacity or bandwidth is limited, it seems
> it would *not* be a good choice to offer services.
>
> Personally, I really don't like the direction this is going,
> if we say that offering a service is a good reason not to be
> a peer. One of the biggest problems with P2P is everyone
> wanting to be a client and not participate in the overlay. If
> a device has enough bandwidth or power to offer services,
> then it *definitely* should be a peer. The more reasons we
> allow to cause a node to be a client rather than a peer, the
> less peers, which means those need to be very powerful, and
> it will be painful to be one, so they will want to be
> clients, so there will be less peers....it spirals.
>
[Hewen]Agree. Incentive measure is important, but it is dependent the application scenarios in the real world. In P2PSIP
overlay network consisting of hosts from unknown Internet, security consideration and incentive measure are mandatory and
must be considered first; but in P2PSIP overlay network consisting of nodes from autonomous system (e.g., Mobile
communication system of an ISP, or enterprises' communication in VPN), incentive measure is not mandatory but optional. I do
also think that we need a smart incentive measure but the incentive measure would be flexible and separate from nodes'
capability, certainly the incentive measure is dependent on nodes' contribution to P2PSIP overlay network. In fact, it is
very difficult (even impossible) to declare that which node has the competency to act as a peer until we have a similar
mechanism like MPLS-TE to be aware of every node's capacity and contribution willing or we use a central server to execute
admission control in P2PSIP overlay network, but any strict (even harsh) admission control will keep many users/nodes far
away from P2PSIP overlay network,  it will block P2PSIP deployment in many autonomous systems.

> If it can possibly be a peer, I think it should be...
[Hewen] I also hope so, it will make the P2PSIP overlay network simple, personally, but it is not feasible in some
application scenarios as above description, do you think so? We will detail the P2PSIP client use cases in an I-D named with
"P2PSIP client requirements" which was mentioned days ago in the mail list.

---

From: Zheng Hewen <[email-masked]>
Date: Thu, 22 Nov 2007 09:42:07 +0800

Hi,

Best regards,
Hewen

> Sent: 2007?11?22? 3:41
> To: David A. Bryan; JiangXingFeng
> A mobile client is more likely to change its IP address and
> thus force a new stabilization process (Chord terminology)
> every time in the overlay.
>
> B. Who Can Be A Peer
> ====================
> Which nodes can declare themselves a peer and which are
> (mobile) clients is a matter of policy by the overlay operator.
>
> The nodes that can declare themselves a peer, within policy,
> will need to meet certain criteria such as:
>
> This topic (B.) deserves a memo written by a design team with
> input from looking first at the existing p2p networks; and
> there are plenty of them.
>
[Hewen] It seems that we need a feasible admission control mechanism. This mechanism may be central policy-based (e.g.,
using central policy server + COPS) or distributed individual (e.g. using flood to synchronizing each nodes' capability and
willing, but it seems not good). This mechanism can work a smart contribution incentive measure.

> it

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 21 Nov 2007 22:15:15 -0500

> A. Client Rationale

A good point!
> B. Who Can Be A Peer

Again a good point!

Thanks.

Eunsoo

-- 
Eunsoo

---

From: JiangXingFeng <[email-masked]>
Date: Thu, 22 Nov 2007 11:17:29 +0800

> Why would being in the overlay be a bad influence?

Here, what I really concerns is the security threat arising from the role of
peer. It is hard to realize high level security in P2P situation. The peer
may at the risk of several kinds of DoS attack which will influence the
service provided by the node.

Maybe I did not express clearly. The nodes which provide service may be
deployed by operators to provide better performance and stability of the
overlay. The operator could reuse existing security methods to protect the
nodes and keep them stable as long as possible. 

Regards!

JiangXingFeng

---

From: Philip Matthews <[email-masked]>
Date: Thu, 22 Nov 2007 08:39:34 -0500

> - BW as seen by the node.

Work by various people has shown how to almost completely eliminate the
second criteria so that even nodes behind NATs with endpoint- 
dependent mapping can
fully participate as peers.

I am less qualified to comment on the first, but wonder whether a  
node that is considered
a security risk should be allowed to join the overlay as a client  
(whatever that means).

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 22 Nov 2007 08:49:41 -0500

>> new stabilization process (Chord terminology) every time in the  

Using any of the HIP-inspired techniques in a make-before-break scenario
(= where a node gains a new address before losing its old address),
this does not seem to be necessarily true. It seems quite possible to
keep all connections up through an address transition.

In fact, I see this as one of the big advantages of the HIP-inspired
techniques for P2PSIP.

The situation for break-before-make is still under investigation.

- Philip

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 22 Nov 2007 14:50:31 +0100

Philip Matthews wrote:
> second criteria so that even nodes behind NATs with endpoint-dependent
> mapping can

Well, probably they can, but, as long as bandwidth is the most scarce
resource, they are not only useless, but also harmfull to the overlay as
they require other peers to relay all their traffic.

Clearly, it would be much better if they were behind NATs with
endpoint-dependent filtering, but endpoint-independent mapping...

---

From: Philip Matthews <[email-masked]>
Date: Thu, 22 Nov 2007 09:05:29 -0500

On 22-Nov-07, at 08:50 , Enrico Marocco wrote:

>> dependent

We know how to set up a direct connection without a relay between a  
node X
behind a NAT with address-and-port-dependent mapping and filtering  
and a node Y behind
a NAT with endpoint-independent mapping and address-dependent filtering.

A small number of nodes like X are not really a problem in an overlay.

- Philip

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 22 Nov 2007 15:32:22 +0100

Philip Matthews wrote:
> We know how to set up a direct connection without a relay between a node X
> behind a NAT with address-and-port-dependent mapping and filtering and a
> node Y behind

The obvious point is how small is small enough.

In many cases an overlay maintained by a selection of available nodes
performs much better than one where all are always involved; I don't
want to take part in the discussion of what clients, peers and user
agents are, but I really hope we don't try to avoid an overlay from
being participated only by a subset of all possible peers.

---

From: Song Yongchao <[email-masked]>
Date: Fri, 23 Nov 2007 14:37:15 +0800

> node X behind a NAT with address-and-port-dependent mapping and 
> filtering and a node Y behind a NAT with endpoint-independent mapping 
> and address-dependent filtering.

As I know, NAT mapping rules and endpoint filtering rules for TCP are
somewhat different from that for UDP, and even for TCP, various packet
sequences for handshaking are filtered by NATs. Do you mean you can set up a
direct connection for all X and Y of that kind you mentioned, or just a
subset of that?

Best Regards!
Song Yongchao

---

From: Zheng Hewen <[email-masked]>
Date: Wed, 28 Nov 2007 15:05:02 +0800

Hi,

    We formed an initial I-D to address :
   * Describe a problem that you want to solve using clients.
   * Present a convincing argument why that problem is interesting.
   * Present a convincing argument why that problem cannot be solved using peers.

   Any  comment is appreciated!

Best regards,
Hewen

> Sent: 2007?11?28? 14:51
> To: [email-masked]
> Cc: Victor Pascual ??vila; [email-masked]; Zheng Hewen
> Subject: Draft about P2PSIP Client Concept
>
> Hi,
>
> We wrote the following draft. Even though the draft is quite
> late for the upcoming IETF meeting, we hope this helps the
> discussion about the Clients in the meeting.
>
>
> title: P2PSIP Clients
> file: draft-pascual-p2psip-clients-00
> Abstract
>
>  This document describes why and when some devices would
> better be a  Client rather than a Peer. The purpose of this
> document is to facilitate the  discussion and understanding
> about the Client node type.
>
> It is available in the link below.
> http://www.ee.columbia.edu/~eunsoo/open2/draft-pascual-p2psip-
> clients-00.txt
>
> It will be submitted to the IETF.
> Thanks.
> --
> Eunsoo
>

> Sent: 2007?11?19? 21:42
> 2) No clear idea why people want clients. So far, the only
> agreed- upon description of a client is that they do
> something less than a peer.
> 3) No clear description of what a client is. Concepts-01
> lists three different alternatives that have been proposed by
> people, and so far there seems to be no WG consensus around
> any of these.
>
> nodes that can and might want to be clients, but cannot be
> peers, though it still doesn't describe WHAT a client is.
>
> Let me be clear. Given a good argument, I am quite willing to
> have the concept of a client. I just need to know what it is
> and why I need it.
>
> - Philip
>
>
>