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

[Gustavo Garcia <[e-mail]>]

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

> 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. 
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
> looking up the location of my callee rather than transport my INVITE
> 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
> 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?
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.
> 
> Thanks.
> 
> Eunsoo
> 
> On Nov 15, 2007 8:23 AM, Spencer Dawkins <[e-mail]> wrote:
> > 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" <[e-mail]>
> >
> > > 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. ]
> >
> >
> >
> 
> 
> 
> 
> 
> --
> Eunsoo
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip


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