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

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

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