Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services?

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 2 Jul 2007 13:24:43 +0200

> Vikas Tandon [mailto:[email-masked]] wrote:
> 
> I'm not sure how well this goes with the SIMPLE concepts. However
doing P2P will increase the traffic between 
> the peers since every presence update needs to be sent to every buddy
in the buddylist which is heavy on the 
> mobile devices and networks. Also P2P will not help in having other
services utilize presence information. 

Presence scalability is an issue even with C/S SIP. The real difficulty
with NOTIFY is that
different watchers may see different presence documents, due to the
presentity's policies.
Off-line presence brings further complications.

Some random thoughts:

If a group of watchers receives the same presence document, an
application layer
multicast may distribute the load between devices. Could
draft-ietf-sip-uri-list-message be abused for this purpose? A peer
receiving a
NOTIFY with a recipient-list forwards it to some contacts mentioned
there
(removing those contacts from the recipient-list before sending).
Possible, but
I don't want to write the Security Considerations section..

Offline presence can be done by storing a user's presence document like
a
file in P2P file sharing networks. To meet the presentity's policy, we
would need some elaborate encryption scheme, so that watchers can only
those parts they are allowed to see. Multiple versions of the presence
document might be necessary, one for every watcher/presentity pair.

Wolfgang

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

---

From: "David Barrett" <[email-masked]>
Date: Mon, 2 Jul 2007 12:06:25 -0700

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:[email-masked]]
> 
> Presence scalability is an issue even with C/S SIP. 

Am I misunderstanding you, or are you saying client-server architectures
have difficulty scaling presence-based applications?  Hasn't AIM, MSN, ICQ,
YahooIM, and basically every IM on the planet successfully demonstrated that
C/S architectures can scale presence-based applications to, well, the entire
planet?

-david

---

From: Song Yongchao <[email-masked]>
Date: Thu, 05 Jul 2007 08:51:04 +0800

I agree with that.
The draft http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-
scaling-analysis-00.txt has shown the complexity and the load that the
presence server has to handle in order to provide its service.
Self-organization infrastructure may help with the scalability of C/S
presence by utilizing the processing resource of the end users.
Using an application layer multicast and uri list message should be a good
choice. 

Sure, there are many questions to be considered, including offline messages,
churn of the p2p network, the presentity's policies, the durability and
availability of the presence information in P2P network and security
considerations.

Best Regards!
Song Yongchao

-----Original Message-----
From: Beck01, Wolfgang [mailto:[email-masked]] 
Sent: 2007年7月2日 19:25
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P
torealize presence and IM services?

Some random thoughts:

a file in P2P file sharing networks. To meet the presentity's policy, we

Wolfgang

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Jul 2007 15:39:51 -0700

Can anyone share a comparison for presence using P2P vs. using SIMPLE client-server? 

At first glance it looks obvious that P2P SIMPLE is the answer, but an analysis would be of great help.

Thanks, Henry

-----Original Message-----
From: Song Yongchao [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2007 7:51 PM
To: 'Beck01, Wolfgang'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services?

I agree with that.

Best Regards!
Song Yongchao

-----Original Message-----
From: Beck01, Wolfgang [mailto:[email-masked]] 
Sent: 2007年7月2日 19:25
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P

Some random thoughts:

Wolfgang

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 19:07:03 -0400

There are definitely a lot of questions to be addressed in making SIMPLE
work in a p2p system.

One the question of RLS services, I would tend to think that they are
not needed in a p2p system. The whole premise of RLS services is that
the server has access to a much richer set of bandwidth and processing
resources. So, let it do the 'fan-out' work of processing the buddy list
and managing the dialogs. In a p2p model, the 'server' would be just
another client on the ring. SO there is no reason to expect that it is
any better suited to perform the task.

MOst of the issues, I think, are really around security and
authorization. Part of a presence server's role is to perform privacy
processing - to limit who can subscribe and to limit what data they can
see. In a client/server system, the presence server can perform this
role since the client trusts its server to do so. In a p2p system, would
you trust some other node in the network to execute your privacy
preferences? I think not.

So, rather, I think that, while online, a user's own user agent would
have to supply the presence for the user. While offline, they would
store a presence document that all would have access to, which indicates
some limited form of offline access. Thus, a user is their own presence
server. That eliminates the need for tools like XCAP and presence
authorization policy documents, since know the user and their presence
server are colocated.

As always, multiple devices are a challenge....

-Jonathan R.

Henry Sinnreich wrote:
> -----Original Message----- From: Song Yongchao
> [mailto:[email-masked]] Sent: Wednesday, July 04, 2007 7:51 PM
>  To: 'Beck01, Wolfgang' Cc: [email-masked]; [email-masked];
> [email-masked] Subject: RE: [P2PSIP] RE: [Simple] Do we need to
> introduce SIMPLE into P2Ptorealize presence and IM services?
> 
> I agree with that. The draft
> http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- 
> scaling-analysis-00.txt has shown the complexity and the load that
> the presence server has to handle in order to provide its service. 
> Using an application layer multicast and uri list message should be a
> good choice.
> 
> Sure, there are many questions to be considered, including offline
> messages, churn of the p2p network, the presentity's policies, the
> durability and availability of the presence information in P2P
> network and security considerations.
> 
> 
> 
> Best Regards! Song Yongchao
> 
> -----Original Message----- From: Beck01, Wolfgang
> [mailto:[email-masked]] Sent: 2007年7月2日 19:25 To:
> [email-masked]; [email-masked]; [email-masked] Cc:
> [email-masked] Subject: AW: [P2PSIP] RE: [Simple] Do we need to
> introduce SIMPLE into P2P torealize presence and IM services?
> 
> Presence scalability is an issue even with C/S SIP. The real
> difficulty with NOTIFY is that different watchers may see different
> presence documents, due to the presentity's policies. Off-line
> presence brings further complications.
> 
> Some random thoughts:
> 
> application layer multicast may distribute the load between devices.
> Could draft-ietf-sip-uri-list-message be abused for this purpose? A
> peer receiving a NOTIFY with a recipient-list forwards it to some
> contacts mentioned there (removing those contacts from the
> recipient-list before sending). Possible, but I don't want to write
> the Security Considerations section..
> 
> Offline presence can be done by storing a user's presence document
> like a file in P2P file sharing networks. To meet the presentity's
> policy, we would need some elaborate encryption scheme, so that
> watchers can only those parts they are allowed to see. Multiple
> versions of the presence document might be necessary, one for every
> watcher/presentity pair.
> 
> 
> Wolfgang
> 
> 
> 
> 
> _______________________________________________ P2PSIP mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/p2psip
> 
> _______________________________________________ P2PSIP mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/p2psip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Jul 2007 16:42:58 -0700

So to summarize in a SIMPLE-istic way: Most of the "SIMPLE problem statement" issues would go away using P2P?

If yes, do you see any other overload problems popping up?

(I fail to see them and Skype meets all of my presence needs).

Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 6:07 PM
To: Henry Sinnreich
Cc: [email-masked]; [email-masked]; [email-masked]; Beck01,Wolfgang
Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 21:27:47 -0400

The problems become entirely different ones. However, from a purely
scale perspective, I'd say a *pure* p2p completely solves it.

The simple-problem statement is based on a model whereby a large amount
of traffic is focused between a pair of large networks, typically
through a small number of servers that serve as the perimeter servers
for each network.

In a p2p model, there is no such perimeter server. If each user agent is
its own presence client and server, the workload is completely
distributed through the network. Each node in the p2p network would have
to support a volume of subscriptions and notifications exactly equal to
the volume associated with its own buddy list. The work per node is not
proportional to the size of the network in any way (at least not at this
layer; the workload of managing the ring scales as logN over N). In
essence, such a network could scale to nearly unbounded sizes without
any kind of central point that becomes a bottleneck.

The penalty for this is going to be primarily loss of functionality.
Offline presence will stink or be non-existent. Presence composition is
limited to the information knowable and obtainable by the endpoint
itself. Multiple endpoints is going to be really awful to handle and
will probably not work very well. Buddy lists and privacy policies, if
stored locally, will suffer from problems when you change computers or
lose your PC. You want to store them in the network, which is doable but
introduces some issues.

The access bandwidth required for this is substantially more than any
configuration we've considered so far; a constant factor larger than the
bandwidth required for a client that doesn't have an RLS, much larger
than for one that does. The security of the system becomes as good as
the p2p security overall, though privacy is arguably better since there
are no intermediaries to trust and you no longer need to signal policy
from a UA to a separate presence server, so you can have more
flexibility there.

However, this is assuming a single global p2p network. If its segmented
into several ones that need to connect via gateways, you're right back
to simple-problem-statement. Though there may be ways to distribute the
gateways if the two federating networks are both p2p. If one is not
(i.e., federate a p2p network with a regular client-server one), that is
definitely having the simple-problem-statement issue.

-Jonathan R.

Henry Sinnreich wrote:
> So to summarize in a SIMPLE-istic way: Most of the "SIMPLE problem
> statement" issues would go away using P2P?
> 
> -----Original Message----- From: Jonathan Rosenberg
> [mailto:[email-masked]] Sent: Thursday, July 05, 2007 6:07 PM To:
> Henry Sinnreich Cc: [email-masked]; [email-masked];
> [email-masked]; Beck01,Wolfgang Subject: Re: [P2PSIP] RE: [Simple]
> Do we need to introduce SIMPLEinto P2Ptorealize presence and IM
> services?
> 
> There are definitely a lot of questions to be addressed in making
> SIMPLE work in a p2p system.
> 
>  not needed in a p2p system. The whole premise of RLS services is
> that the server has access to a much richer set of bandwidth and
> processing resources. So, let it do the 'fan-out' work of processing
> the buddy list and managing the dialogs. In a p2p model, the 'server'
> would be just another client on the ring. SO there is no reason to
> expect that it is any better suited to perform the task.
> 
>  processing - to limit who can subscribe and to limit what data they
> can see. In a client/server system, the presence server can perform
> this role since the client trusts its server to do so. In a p2p
> system, would you trust some other node in the network to execute
> your privacy preferences? I think not.
> 
> store a presence document that all would have access to, which
> indicates some limited form of offline access. Thus, a user is their
> own presence server. That eliminates the need for tools like XCAP and
> presence authorization policy documents, since know the user and
> their presence server are colocated.
> 
>> [mailto:[email-masked]] Sent: Wednesday, July 04, 2007 7:51
>> PM To: 'Beck01, Wolfgang' Cc: [email-masked];
>> [email-masked]; [email-masked] Subject: RE: [P2PSIP] RE: [Simple]
>> Do we need to introduce SIMPLE into P2Ptorealize presence and IM
>> services?
>> 
>>  Self-organization infrastructure may help with the scalability of
>> C/S presence by utilizing the processing resource of the end users.
>>  Using an application layer multicast and uri list message should
>> be a good choice.
>> 
>> application layer multicast may distribute the load between
>> devices. Could draft-ietf-sip-uri-list-message be abused for this
>> purpose? A peer receiving a NOTIFY with a recipient-list forwards
>> it to some contacts mentioned there (removing those contacts from
>> the recipient-list before sending). Possible, but I don't want to
>> write the Security Considerations section..
>>

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 6 Jul 2007 13:27:31 -0400

> lose your PC. You want to store them in the network, which is doable but

A slightly different model is to have the presence information stored
on the responsible peer for the user's registration.   That has the
same global load balancing and traffic charactersitics as having the
user's own UA handle presence traffic, except that it transfers the
load from the user's own UA to whatever peer randomly winds up being
responsible for the registration.  I think it's reasonable to argue
that this is unfair and that the user's own UA should handle presence
when online (pay your own price for having 200 friends, etc).

I don't think we should give up on good offline presence, though, so I
think we still need to have the responsible peer capable of acting as
the PA when the user has no online UA.  A lot of use-cases for P2PSIP
require offline storage (for voicemail, buddy lists, etc), so having
the responsible peer handle presence when the user has no active UA
seems like a natural extension.  Migration of subscriptions is
well-defined, so no new mechanisms are needed.  Since the user is
offline and presumably has static presence status, using a longer
expiration to reduce load seems reasonable, and the responsible peer
would know when the user is again online so that the responsible peer
can send a final NOTIFY that forces the subscriptions to migrate to
the user's UA again.

Bruce