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

[Zheng Hewen <[e-mail]>]

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


> -----Original Message-----
> From: Eunsoo Shim [mailto:[e-mail]]
> Sent: 2007?11?15? 23:21
> To: Spencer Dawkins
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior
>
> 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
>
> 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.t
> > xt) 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