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

["Eunsoo Shim" <[e-mail]>]

On Nov 15, 2007 11:13 AM, Gustavo Garcia <[e-mail]> wrote:
> 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.
>
Neither of the above requirement means many or all of the Peers must
be coupled with SIP Proxy entity.

> > 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.
>
Right. The first SIP Proxy is on a Peer in this case.
I meant what you wrote but put it wrongly.

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

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.

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

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

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



-- 
Eunsoo

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