Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior

Spencer Dawkins <spencer@mcsr-labs.org> Thu, 15 November 2007 13:24 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isehr-0008Bn-9z; Thu, 15 Nov 2007 08:24:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isehq-0008BP-G8 for p2psip@ietf.org; Thu, 15 Nov 2007 08:24:30 -0500
Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isehp-0002wB-R7 for p2psip@ietf.org; Thu, 15 Nov 2007 08:24:30 -0500
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRJ00MX8UKQTG@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 05:24:27 -0800 (PST)
Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRJ00IGZUKMF7@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 05:24:26 -0800 (PST)
Date: Thu, 15 Nov 2007 07:23:29 -0600
From: Spencer Dawkins <spencer@mcsr-labs.org>
Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior
To: 'P2PSIP Mailing List' <p2psip@ietf.org>
Message-id: <0aef01c8278a$b68ad0e0$ad600240@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

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" <philip_matthews@magma.ca>

> 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.
>> 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?
>
> Right now, the reference model identifies three types of nodes: (a)
> peers, (b) clients, and (c) SIP UAs that attach via an proxy.

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

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
>> 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.
>
> I am still waiting for that agreement.

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



_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip