Subject: [Simple] how to reduce no of subscribe between rls and presence....

From: "HEM" <[email-masked]>
Date: Fri, 6 Oct 2006 10:34:45 +0530

Dear  SIMPLE  subscribers,

My query : In my presence design there are 30 peoples who should subscribe
all each other. This means every user has buddies of all other 29 peoples.

Problem: Every user sends subscribe to list (RLS). RLS sends 29 subscribe to
Presence server to get the status in the Notification.

All the 30 users subscribes to rls then 30 X 29 = 870 subscribe is sent to
the Presence server. Now almost same 30 notification goint to sent 29 times.
Is there any possible to reduce this subscription rate. 

Eg. While sending first user subscribe we get all 30 persons notification.
Is there any possibility to avoid other persons subscription to send it to
presence....

Is there any document speaks about this???

Expecting your suggestions help me...

By

Hem

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

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 6 Oct 2006 13:51:34 +0200

There should only be 30 subscriptions between the RLS and the Presence 
Server.

The RLS server will not generate multiple subscriptions to the same 
resource.

Imagine you have users A, B and C. they belong to the list 
[email-masked]. The RLS will only send one SUBSCRIBE to A, one 
SUBSCRIBE to B, and one SUBSCRIBE to C. Any NOTIFY resulting from those 
3 subscriptions will trigger a NOTIFY to A, B and C.

Hisham

On Oct 6, 2006, at 7:04 AM, HEM wrote:

> Dear  SIMPLE  subscribers,
> My query : In my presence design there are 30 peoples who should 
> subscribe all each other. This means every user has buddies of all 
> other 29 peoples.
> Problem: Every user sends subscribe to list (RLS). RLS sends 29 
> subscribe to Presence server to get the status in the Notification.
> All the 30 users subscribes to rls then 30 X 29 = 870 subscribe is 
> sent to the Presence server. Now almost same 30 notification goint to 
> sent 29 times. Is there any possible to reduce this subscription rate.
> Eg. While sending first user subscribe we get all 30 persons 
> notification. Is there any possibility to avoid other persons 
> subscription to send it to presence……….
> Expecting your suggestions help me…..
>  
> By
> Hem

---

From: <[email-masked]>
Date: Fri, 6 Oct 2006 15:35:15 +0300

Hi,

I think the issue is similar to what is also described in http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-00.txt.

If the same RLS/domain has N lists which each contain user A, how many SUBSCRIBEs does it send? If we don't consider authorization, the RLS could do just a single subscription to user A, which would be a very scalable approach. However, authorization messes this up. User A may have totally different policies to different actual subsrcibers sharting the RLS. Thus, the RLS has to do separate subsrciption for each list with the credentials of each list owner. 

One practical consideration is that if the presence document is not encrypted by S/MIME (with each subscriber's public key), the RLS will anyway see all the data so the Presence Server and User A would have to trust the RLS. So, without S/MIME in the picture, as I assume the things to be, the security properties would still be the same in both cases.

So, perhaps, between domains that have some kind of special trust relationship (and certainly witin a single domain) the optimization could still be done together with authorization. The model would be that the RLS would just send a single SUBCSCRIBE to User A, listing the actual subscribers. The Presence Server would generate some kind of huge NOTIFY that contains instructions which presence state the RLS should distribute to which actual subscriber. The trustworthy RLS would then act upon this and not leak info between subscribers. 

Is this kind of approach something that people would like to work with? The security considerations are tricky, but if people come up with concrete data that interdomain presence does not scale well without this (I don't have any facts about this), we should at least investigate it.

The RLS could additionally use http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe-00.txt between domains to further optimize the signaling load.

Markus

>-----Original Message-----
>From: ext Hisham Khartabil [mailto:[email-masked]] 
>Sent: 06 October, 2006 14:52
>To: HEM
>Cc: [email-masked]
>Subject: Re: [Simple] how to reduce no of subscribe between 
>rls andpresence....
>
>There should only be 30 subscriptions between the RLS and the 
>Presence Server.
>
>The RLS server will not generate multiple subscriptions to the 
>same resource.
>
>[email-masked]. The RLS will only send one SUBSCRIBE to A, 
>one SUBSCRIBE to B, and one SUBSCRIBE to C. Any NOTIFY 
>resulting from those
>> subscription to send it to presence..........
>> Expecting your suggestions help me.....
>>  
>> By
>> Hem

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Oct 2006 08:45:15 -0400

> 3 subscriptions will trigger a NOTIFY to A, B and C.

Hisham,

The problem is that the presence authorization rules for each user may 
alter what is published depending on who is subscribing. When B 
subscribes to A he may get a different result than when C subscribes to 
A. So when B and C each subscribe to an RLS referencing A they should 
again get different results.

Without some substantial changes to the existing mechanisms, or a very 
tight and proprietary relationship between the RLS and the presence 
server, I don't think the approach you suggest can achieve that.

One solution to this is to have the RLS subscribe based on its own 
identity rather than the identity of its subscribers. But that will be 
quite a different authorization model.

	Paul

---

From: David Viamonte <[email-masked]>
Date: Fri, 06 Oct 2006 16:22:44 +0200

One comment about this.

First of all, I agree it seems quite reasonable, from a "common sense"
point of view.

However, as Paul indicates, I think Presence Authorization rules have
an impact in this architecture. In principle, a Presentity stores its
authorization rules in a XCAP server, which is accessed by the Presence
Server to decide which information to send to each subscribed watchers.

If the RLS tries to get a full Presence document from the Presence
Server, then the RLS itself will have to filter out Presence
information to each subscribing Watcher. In this case the RLS itself
has to be connected to the XCAP server and retrieve (and apply)
Presence authorization rules... I think this is not the current model
for the Presence architecture.

I don't say the RLS could not do that, but then the Presence Server and
RLS functionality become progressively mixed up (?).

Comments welcome.

Regards,

David

[email-masked] escribió:

Hi,

Markus

-----Original Message-----
From: ext Hisham Khartabil [mailto:[email-masked]]
Sent: 06 October, 2006 14:52
To: HEM
Cc: [email-masked]
Subject: Re: [Simple] how to reduce no of subscribe between
rls andpresence....

Hisham

Dear  SIMPLE  subscribers,
sent to the Presence server. Now almost same 30 notification

goint to

sent 29 times. Is there any possible to reduce this

subscription rate.

By
Hem

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 6 Oct 2006 16:56:18 +0200

You are right and I do not dispute that. I was only addressing Hem's  
specific use case where everybody is subscribing to everybody in what I  
assumed is a closed enterprise presence solution. But again you are  
right, I dislike some of my colleagues as well :)

Considering your issue with authorisation rules, I was thinking of the  
following solution ( a variation of yours I think):

- The SUBSCRIBE for a certain presentity between the RLS and the PS  
contains a body containing the list of watchers (a variation to  
draft-ietf-sip-uri-list-subscribe-00.txt). This could be just one  
watcher at the beginning
- The Presence server generates different presence info, one for each  
of the watchers listed in the SUBSCRIBE. It then puts those in one  
NOTIFY (a variation to RFC 4662, RLS RFC)
- When a new watcher subscribers to that presentity, the RLS would  
refresh the subscription and add another watcher to that watcher list

Thoughts?

Hisham

On Oct 6, 2006, at 2:35 PM, <[email-masked]> wrote:

> Hi,
>
> I think the issue is similar to what is also described in  
> http://www.ietf.org/internet-drafts/draft-rang-simple-problem- 
> statement-00.txt.
>
> If the same RLS/domain has N lists which each contain user A, how many  
> SUBSCRIBEs does it send? If we don't consider authorization, the RLS  
> could do just a single subscription to user A, which would be a very  
> scalable approach. However, authorization messes this up. User A may  
> have totally different policies to different actual subsrcibers  
> sharting the RLS. Thus, the RLS has to do separate subsrciption for  
> each list with the credentials of each list owner.
>
> One practical consideration is that if the presence document is not  
> encrypted by S/MIME (with each subscriber's public key), the RLS will  
> anyway see all the data so the Presence Server and User A would have  
> to trust the RLS. So, without S/MIME in the picture, as I assume the  
> things to be, the security properties would still be the same in both  
> cases.
>
> So, perhaps, between domains that have some kind of special trust  
> relationship (and certainly witin a single domain) the optimization  
> could still be done together with authorization. The model would be  
> that the RLS would just send a single SUBCSCRIBE to User A, listing  
> the actual subscribers. The Presence Server would generate some kind  
> of huge NOTIFY that contains instructions which presence state the RLS  
> should distribute to which actual subscriber. The trustworthy RLS  
> would then act upon this and not leak info between subscribers.
>
> Is this kind of approach something that people would like to work  
> with? The security considerations are tricky, but if people come up  
> with concrete data that interdomain presence does not scale well  
> without this (I don't have any facts about this), we should at least  
> investigate it.
>
> The RLS could additionally use  
> http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe 
> -00.txt between domains to further optimize the signaling load.
>
> Markus
>
>

---

From: David Viamonte <[email-masked]>
Date: Fri, 06 Oct 2006 17:40:43 +0200

(forget my previous post, as I think it contained obvious already 
discussed topics)

Proposal looks interesting.

One additional thought:

Why not using or adapting content indirection to this case? That is: 
Presence documents are posted in a content server, so only the reference 
is provided by the PS to the RLS. If two users are entitled to receive 
the same information, the URL may be the same, so the RLS does not need 
to retrieve that document twice. This solution could save a lot of 
traffic between domains, and  oit is not against Hisham's proposals (it 
can be combined with some of them).

A lot of thinking may be required yet, but perhaps it can be considered...

Cheers,

David

Hisham Khartabil escribió:
> specific use case where everybody is subscribing to everybody in what 
> I assumed is a closed enterprise presence solution. But again you are 
>> http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-00.txt. 
>>
>>
>> If the same RLS/domain has N lists which each contain user A, how 
>> many SUBSCRIBEs does it send? If we don't consider authorization, the 
>> RLS could do just a single subscription to user A, which would be a 
>> very scalable approach. However, authorization messes this up. User A 
>> may have totally different policies to different actual subsrcibers 
>> of huge NOTIFY that contains instructions which presence state the 
>> RLS should distribute to which actual subscriber. The trustworthy RLS 
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe-00.txt 
>> between domains to further optimize the signaling load.
>>
>> Markus
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Oct 2006 11:56:29 -0400

Hisham Khartabil wrote:
> - The Presence server generates different presence info, one for each of 
> the watchers listed in the SUBSCRIBE. It then puts those in one NOTIFY 
> (a variation to RFC 4662, RLS RFC)

I think something could be made to work this way, that would work in 
some circumstances. But it has some very complex authorization issues:

- the RLS will have to authenticate and be authorized by the PS
   using some identity - presumably its own.

- the PS will have to trust the RLS as much as the union of all
   the watchers the RLS represents.

- the PS will also have to trust the RLS to distribute the returned
   info in the agreed upon way.

In general there is no reason to expect a close relationship between the 
RLS and the PS for *all* of the presentities in the list. In particular, 
as soon as a list includes presentities from two trust domains this 
assumption will be violated.

So I don't think the above can be a full solution.

	Paul

---

From: David Viamonte <[email-masked]>
Date: Sat, 7 Oct 2006 13:51:09 +0200

(forget my previous post as it contained obvious statements ;-)

Regardless, one additional thought: wouldn't it make sense to adapt Content 
Indirection to this type of cases? That is: the RLS subscribes and the PS 
sends a NOTIFY message containing a reference (URL) to the location of a 
Presence document.

In case two watchers are entitled to receive the same Presence information, 
the PS would send the same URL, so the RLS would not need to download the same 
document twice. 

Subsequent notifications could work the same... It does not remove 100% of the 
redundant traffic, but I think it certainly helps.

I think significant work might be required to define a complete solution and 
ensure full synch between Presence documents across PS, RLS and the content 
server, but giving a thought about the idea could be helpful, perhaps, in 
scope of this discussion. IMMO, I think a well-defined framework around 
content indirection should be useful to reduce overall Presence traffic within 
and across domains.

Regards,

David

> So I don't think the above can be a full solution.

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

---

From: "HEM" <[email-masked]>
Date: Mon, 9 Oct 2006 11:34:05 +0530

Hi David,
Really good idea to do content indirection.
What I understand from this is: client sends request to rls. Rls resolves
and sends no of subscribe and receives no of notify equal to buddylist. But
the notify contains content indirection (http uri to get presence document
from xcap server present in the presence server)instead of whole content.
Then rls requests xcap server to get pidf doc and caches to send to the
clients who are all requests for that resource.
The problem here I guess is : 
Scenario: user A wants user c document. Now user c doc is in rls cache. If
the user b wants the same user c doc. Rls will not make again the request
and it just sends the cache c. 
Problem: the gap between request of A and B user c may change his status.
How it will be reflected to the user B.

Can you please tell me the documents which deals about this.

Thanking you,
Regards
hem

-----Original Message-----
From: David Viamonte [mailto:[email-masked]] 
Sent: Saturday, October 07, 2006 5:21 PM
To: [email-masked]
Subject: Re: [Simple] how to reduce no of subscribe between rls
andpresence....

In case two watchers are entitled to receive the same Presence information, 
the PS would send the same URL, so the RLS would not need to download the
same 
document twice. 

Subsequent notifications could work the same... It does not remove 100% of
the 
redundant traffic, but I think it certainly helps.

ensure full synch between Presence documents across PS, RLS and the content 
server, but giving a thought about the idea could be helpful, perhaps, in 
scope of this discussion. IMMO, I think a well-defined framework around 
content indirection should be useful to reduce overall Presence traffic
within 
and across domains.

Regards,

David

---

From: David Viamonte <[email-masked]>
Date: Mon, 09 Oct 2006 09:20:26 +0200

Thanks for your feedback,

This is not referenced in any document, it came to my mind as the
discussion moved forward ;-)

I am happy to work in the idea, though, if it makes any sense to the
SIMPLE WG.

Regarding your
question: remember that the PS will send a NOTIFY every time there is a
Presence update. Thus, the PS would indeed send a notification whenever
the Presence document has changed. Perhaps
the content
indirection mechanism
for this type of cases should contain some additional parameter to guarantee permanent
synch and ensure that the RLS retrieves the most updated Presence
document when needed. Possibly something similar to the "etag"
attribute (?).

Comments are welcome.

Cheers,

David

HEM escribió:

Hi David,

Thanking you,
Regards
hem

-----Original Message-----
From: David Viamonte [mailto:[email-masked]]
Sent: Saturday, October 07, 2006 5:21 PM
To: [email-masked]
Subject: Re: [Simple] how to reduce no of subscribe between rls
andpresence....

Regards,

David

Hisham Khartabil wrote:

Thoughts?

Paul

---

From: Hartley Mendoza <[email-masked]>
Date: Fri, 06 Oct 2006 13:24:05 +0800

To: HEM

I am a developer for opensipstack and had this problem ever since, and 
with your query that seems to be a major problem when stress testing a 
Presence Agent.
Your calculations are great and I don.t think that there would be any 
reduction to the number of NOTIFY's to be sent by the server since every 
NOTIFY message
corresponds to a certain resource.

But if anyone out there can help us, it would be great.

Thanks

HEM wrote:
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.407 / Virus Database: 268.13.0/464 - Release Date: 10/5/2006
>

---

From: Hartley Mendoza <[email-masked]>
Date: Fri, 06 Oct 2006 13:24:05 +0800

To: HEM

Thanks