Subject: [Simple] Other proposal from View Sharing and Common Notify to reduce presence traffic

From: Victoria Beltrán Martínez <[email-masked]>
Date: Wed, 15 Oct 2008 19:10:37 +0200

Hi,

The Common Notify technique (described in the expired draft "Scaling 
Optimizations for Presence in SIP/SIMPLE, 
houri-simple-interdomain-scaling-optimizations-00) is intended for 
reducing presence traffic between federated domains. Other draft, 
"Optimizing Federated Presence with View Sharing" 
(ietf-simple-view-sharing-01) has the same intention. From these 
proposals,  I was thinking the idea of a single subscription between 
watcher and watched domains, so that the presence server in the watcher 
domain is in charge of subscribing to the watched presentity.  Then, the 
presence server mantains the list of watchers that are watching each 
presentity and this list hasn't to be sent in NOTIFY messages. In this 
way, we avoid the increase of signaling traffic as the number of 
watchers grows in the case of Common Notify and as the number of privacy 
filters grows in the case of View Sharing.

Have anyone considered this solution? I have read nothing about it.

I named this solution as Common Subscribe and compared it with Common 
Notify and View Sharing. I did several assumptions based on IETF drafts 
and I proved that Common Subscribe reduces around  50% of presence 
traffic generated by View Sharing and Common Notify.

thanks,
Victoria
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 16 Oct 2008 17:59:34 -0400

What about allowed/blocked list that a presentity may have, if there is a single subscription between watcher domain's presence server and the watcher presentity.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Victoria Beltrán Martínez
>Sent: Wednesday, October 15, 2008 1:11 PM
>To: [email-masked]
>Subject: [Simple] Other proposal from View Sharing and Common 
>Notify to reduce presence traffic
>
>Hi,
>
>The Common Notify technique (described in the expired draft 
>"Scaling Optimizations for Presence in SIP/SIMPLE,
>houri-simple-interdomain-scaling-optimizations-00) is intended 
>for reducing presence traffic between federated domains. Other 
>draft, "Optimizing Federated Presence with View Sharing" 
>(ietf-simple-view-sharing-01) has the same intention. From 
>these proposals,  I was thinking the idea of a single 
>subscription between watcher and watched domains, so that the 
>presence server in the watcher domain is in charge of 
>subscribing to the watched presentity.  Then, the presence 
>server mantains the list of watchers that are watching each 
>presentity and this list hasn't to be sent in NOTIFY messages. 
>In this way, we avoid the increase of signaling traffic as the 
>number of watchers grows in the case of Common Notify and as 
>the number of privacy filters grows in the case of View Sharing.
>
>I named this solution as Common Subscribe and compared it with 
>Common Notify and View Sharing. I did several assumptions 
>based on IETF drafts and I proved that Common Subscribe 
>reduces around  50% of presence traffic generated by View 
>Sharing and Common Notify.
>
>thanks,
>Victoria

---

From: David Viamonte <[email-masked]>
Date: Fri, 17 Oct 2008 03:59:27 +0200

Hi,

I agree with Sanjay that, at first sight, it seems that for this
alternate proposal to work, a sharing of (part?) of the Presence
authorization policies between serving and watching domains is needed.
On the other hand, making a single "domain-to-domain" subscription as
Victoria suggests would be the simplest and probably most simple
mechanism to distribute Presence information across domains. In such
case the watching domain (RLS) would have responsibility of
implementing Presence policies about Presentities in remote domains.

In practice, the need for sharing policy documents is implicitly
mentioned in the "Security Considerations" section of
"draft-ietf-sipping-presence-scaling-requirements-01". According to
that section, no decision has been made yet about allowing or
discouraging such approach (delegating privacy protection from one
domain to the other). On the contrary, it seems to be left FFS to
decide whether this is an acceptable security risk or not ("important
part of work on the requirements and optimizations will be to make sure
that all the security aspects are covered").

Furthermore, my
understanding is that, in practice, this "domain-to-domain single
subscription" mechanism does not require the complete Presence or
Policy documents being exchanged, only those that might be applicable
to any user in the watching domain (of course, including a mechanism to
update policies, if needed).  In fact, I
think EXACTLY the same comments in the Security Considerations section
of the
View Sharing draft ("if it
generated a subscription from each of its subscribers it would be able
to determine who from its domain is allowed to subscribe and what view
they would receive") are applicable to Victoria's
proposal, so I fail to
see substantial security differences between both approaches. I could envisage
potential "logistic" issues, though...

Since I am not a security expert, my conclusion is that getting an
understanding on whether there are fundamental diferences (from the
security perspective) between both approaches would be very valuable.
In case there are not such differences, the proposed alternative looks
interesting, as it seems to represent a very important simplification
(in practice, there would be no need to define any SIP extension at
all). It is fair to say that a mechanism to exchange policies would
need to be defined (not sure is that is covered elsewhere?).

When it comes to traffic reduction, my understanding is that the
"common subscription" mechanism "should" be more efficient than the
view sharing approach. Even though it leads to larger documents being
exchanged (thus containing more Presence information, which is subject
to more frequent change), such documents are delivered only once per
domain, while in the view sharing case documents are delivered to each
list of watchers sharing a same "policy profile". This is only a
preliminary comment without having made serious calculations :-)

Just my 2 cents,

David

Sanjay Sinha (sanjsinh) escribió:

-----Original Message-----

Hi,

thanks,
Victoria

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.8.1/1728 - Release Date: 16/10/2008 7:38

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com 
Version: 8.0.173 / Virus Database: 270.8.1/1728 - Release Date: 16/10/2008 7:38
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Victoria Beltrán Martínez <[email-masked]>
Date: Fri, 17 Oct 2008 19:13:37 +0200

Hi,

Certainly I considered a mechanism to exchange the policy documents of 
watched presentities between watching and watched domains in Common 
Subscribe solution. The watching domain (RLS) subscribes to an event 
(called “privacy filters”) in presentity domain’s presence server. 
Whenever a change in the policy documents for any of the presentity’s 
watchers happens, a NOTIFY message with “event=privacy filters” is sent 
from presentity’s presence server to watchers’ domain. The watching RLS 
maintains one subscription to “privacy filters” event per watched 
presentity. This subscription could be explicit if existing watchers 
were indicated into the body of SUBSCRIBE messages. In this way, when a 
new watcher is added a re-SUBSCRIBE message containing the updated 
watcher list is sent and a NOTIFY message with the policy documents will 
be received by the RLS in response to this resubscription. However, a 
privacy filters subscription could be implicit so that the watcher list 
is not needed in SUBSCRIBE messages, a simple SUBSCRIBE creates a 
subscription to all the existing watchers of the watched presentity. 
Clearly, a trust relationship between watching RLS and watched PS is 
needed to share full-state presence and policy documents of watched 
presentities.

When the watching domain subscribes to a presentity, the SUBSCRIBE 
message contains the list of existing watchers in order to let the 
watched domain know what watchers are watching the presentity. The OK 
response from the watched domain includes the list of authorized 
watchers to see some view of the presentity’s presence. A view of 
presence is defined by a policy document.

Assuming N watched presentities , with Common Subscribe the watching RLS 
will maintain 2*N subscriptions (N for presence event and N for privacy 
filters event). In case of View Sharing, the RLS will maintain N*F 
setting F as the number of different policy documents per presentity. At 
first sight, we can imagine how the performance of VS gets worse as F 
increases.

In addition, the fact that policy documents change rarely allows us one 
interesting possibility with Common Subscribe. When a common 
subscription is created for a presentity in the watched domain’s 
Presence Server, automatically a “logical” subscription to the policy 
documents associated to the presentity is created too. In this way, the 
watching domain receives two initial NOTIFY messages (or a single 
multipart NOTIFY), one contains the presentity’s presence and another 
one contains the policy documents. Once the policy documents are 
downloaded is more than likely that privacy rules don’t change during 
the session, so that we save unnecessary signaling traffic to keep alive 
subscriptions to privacy filters events. Anyway, if a change of privacy 
rules associated to a presentity happened it would be notified as a 
NOTIFY message into the common subscription between the presentity and 
the affected watchers’ domain. Now, if there are N presentities, the 
total number of subscriptions maintained by the watching RLS is N. I 
have called this mechanism as internal privacy filters subscription.

I did several assumptions to estimate the performance of Common 
Subscribe and View Sharing. I supposed the presence federation scenarios 
described in section 2.8 of the draft “Presence Interdomain Scaling 
Analysis for SIP/SIMPLE”) (ietf-simple-interdomain-scaling-analysis-04). 
I considered both implicit and internal privacy filters subscriptions 
when Common Subscribe was applied. With View Sharing, I agree with David 
that filter-based subscriptions are subject to less frequent change, so 
I supposed that each change affected half of the privacy filters on 
average (a notification was generated in half of the existing 
filter-based subscriptions on average). The number of filter-based 
subscriptions between watching and watched domains is equal to the 
number of different policy documents associated to watchers in the 
watching domain. I considered several numbers of policy documents 
depending on the number of watchers per presentity. My calculations show 
that Common Subscribe is more scalable than View Sharing and it achieves 
around 50% improvement of presence traffic in the majority of cases.

Regards,

Victoria

En/na David Viamonte ha escrit:
> part of work on the requirements and optimizations will be to make 
> sure that all the security aspects are covered").
>
> Furthermore, my understanding is that, in practice, this 
> "domain-to-domain single subscription" mechanism does not require the 
> complete Presence or Policy documents being exchanged, only those that 
> might be applicable to any user in the watching domain (of course, 
> including a mechanism to update policies, if needed). In fact, I think 
> EXACTLY the same comments in the Security Considerations section of 
> the View Sharing draft ("if it generated a subscription from each of 
> its subscribers it would be able to determine who from its domain is 
> allowed to subscribe and what view they would receive") are applicable 
> to Victoria's proposal, so I fail to see substantial security 
> differences between both approaches. I could envisage potential 
> "logistic" issues, though...
>
>> ------------------------------------------------------------------------
>>
>>
> ------------------------------------------------------------------------
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Oct 2008 13:24:54 -0400

Do you *really* want to trust other domains to enforce your security 
policies???

I don't. At least not in general. (Maybe there are *some* other domains 
I would trust to do so.)

	Thanks,
	Paul

Victoria Beltrán Martínez wrote:
>>> What about allowed/blocked list that a presentity may have, if there 
>>> is a single subscription between watcher domain's presence server and 
>>> the watcher presentity.
>>>
>>>
>>>
>>>  
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Victoria Beltrán Martínez
>>>> Subject: [Simple] Other proposal from View Sharing and Common Notify 
>>>> to reduce presence traffic
>>>>
>>>> Hi,
>>>>
>>>> watcher and watched domains, so that the presence server in the 
>>>> watcher domain is in charge of subscribing to the watched 
>>>> presentity.  Then, the presence server mantains the list of watchers 
>>>> that are watching each presentity and this list hasn't to be sent in 
>>>> NOTIFY messages. In this way, we avoid the increase of signaling 
>>>> traffic as the number of watchers grows in the case of Common Notify 
>>>> and as the number of privacy filters grows in the case of View Sharing.
>>>>
>>>> Common Notify and View Sharing. I did several assumptions based on 
>>>> IETF drafts and I proved that Common Subscribe reduces around  50% 
>>>> of presence traffic generated by View Sharing and Common Notify.
>>>>
>>>> thanks,
>>>> Victoria
>>> Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus 
>>> Database: 270.8.1/1728 - Release Date: 16/10/2008 7:38
>>>
>>>   
>> Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 
>> 270.8.1/1728 - Release Date: 16/10/2008 7:38
>>
>>   
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 17 Oct 2008 13:38:06 -0400

Paul,

The presentity has to grant some trust to the watching domain no matter 
what, since all NOTIFYs pass through the RLS in the watching domain.  In 
the case of view-sharing, you (the presentity) trust the watching domain 
to hand out the right views to the right watchers.  Even in the base 
case, you're trusting the RLS not to mix subscriptions up.

Victoria's proposal could be viewed as another level in the trust 
taxonomy in view-sharing, with a corresponding reduction in NOTIFY traffic.
Case	  Policy      NOTIFYs per PUBLISH
No        (nothing)   #WRs
Minimal   WR->view    #views
Partial   WR*->view   #views
Full-VS   WR*->view*  #views
Full-VBM  WR*->rule*  1

--Richard

Paul Kyzivat wrote:
>> watchers happens, a NOTIFY message with “event=privacy filters” is 
>> sent from presentity’s presence server to watchers’ domain. The 
>> watching RLS maintains one subscription to “privacy filters” event per 
>> watched presentity. This subscription could be explicit if existing 
>> watchers were indicated into the body of SUBSCRIBE messages. In this 
>> way, when a new watcher is added a re-SUBSCRIBE message containing the 
>> updated watcher list is sent and a NOTIFY message with the policy 
>> documents will be received by the RLS in response to this 
>> resubscription. However, a privacy filters subscription could be 
>> implicit so that the watcher list is not needed in SUBSCRIBE messages, 
>> a simple SUBSCRIBE creates a subscription to all the existing watchers 
>> of the watched presentity. Clearly, a trust relationship between 
>> watching RLS and watched PS is needed to share full-state presence and 
>> policy documents of watched presentities.
>>
>> Assuming N watched presentities , with Common Subscribe the watching 
>> RLS will maintain 2*N subscriptions (N for presence event and N for 
>> privacy filters event). In case of View Sharing, the RLS will maintain 
>> N*F setting F as the number of different policy documents per 
>> presentity. At first sight, we can imagine how the performance of VS 
>> gets worse as F increases.
>>
>> In addition, the fact that policy documents change rarely allows us 
>> one interesting possibility with Common Subscribe. When a common 
>> documents associated to the presentity is created too. In this way, 
>> the watching domain receives two initial NOTIFY messages (or a single 
>> the session, so that we save unnecessary signaling traffic to keep 
>> alive subscriptions to privacy filters events. Anyway, if a change of 
>> privacy rules associated to a presentity happened it would be notified 
>> as a NOTIFY message into the common subscription between the 
>> presentity and the affected watchers’ domain. Now, if there are N 
>> presentities, the total number of subscriptions maintained by the 
>> watching RLS is N. I have called this mechanism as internal privacy 
>> filters subscription.
>>
>> Subscribe and View Sharing. I supposed the presence federation 
>> scenarios described in section 2.8 of the draft “Presence Interdomain 
>> Scaling Analysis for SIP/SIMPLE”) 
>> (ietf-simple-interdomain-scaling-analysis-04). I considered both 
>> implicit and internal privacy filters subscriptions when Common 
>> Subscribe was applied. With View Sharing, I agree with David that 
>> filter-based subscriptions are subject to less frequent change, so I 
>> supposed that each change affected half of the privacy filters on 
>> depending on the number of watchers per presentity. My calculations 
>> show that Common Subscribe is more scalable than View Sharing and it 
>> achieves around 50% improvement of presence traffic in the majority of 
>> cases.
>>
>> Regards,
>>
>> Victoria
>>
>>
>>> authorization policies between serving and watching domains is 
>>> needed. On the other hand, making a single "domain-to-domain" 
>>> subscription as Victoria suggests would be the simplest and probably 
>>> most simple mechanism to distribute Presence information across 
>>> domains. In such case the watching domain (RLS) would have 
>>> responsibility of implementing Presence policies about Presentities 
>>> in remote domains.
>>>
>>> complete Presence or Policy documents being exchanged, only those 
>>> that might be applicable to any user in the watching domain (of 
>>> course, including a mechanism to update policies, if needed). In 
>>> fact, I think EXACTLY the same comments in the Security 
>>> Considerations section of the View Sharing draft ("if it generated a 
>>> subscription from each of its subscribers it would be able to 
>>> determine who from its domain is allowed to subscribe and what view 
>>> they would receive") are applicable to Victoria's proposal, so I fail 
>>> to see substantial security differences between both approaches. I 
>>> could envisage potential "logistic" issues, though...
>>>
>>> In case there are not such differences, the proposed alternative 
>>> looks interesting, as it seems to represent a very important 
>>> simplification (in practice, there would be no need to define any SIP 
>>> extension at all). It is fair to say that a mechanism to exchange 
>>> policies would need to be defined (not sure is that is covered 
>>> elsewhere?).
>>>
>>> exchanged (thus containing more Presence information, which is 
>>> subject to more frequent change), such documents are delivered only 
>>> once per domain, while in the view sharing case documents are 
>>> delivered to each list of watchers sharing a same "policy profile". 
>>> This is only a preliminary comment without having made serious 
>>> calculations :-)
>>>
>>> Just my 2 cents,
>>>
>>> David
>>>
>>>
>>>
>>>
>>>> is a single subscription between watcher domain's presence server 
>>>> and the watcher presentity.
>>>>
>>>>
>>>>
>>>>  
>>>>> proposals,  I was thinking the idea of a single subscription 
>>>>> between watcher and watched domains, so that the presence server in 
>>>>> the watcher domain is in charge of subscribing to the watched 
>>>>> presentity.  Then, the presence server mantains the list of 
>>>>> watchers that are watching each presentity and this list hasn't to 
>>>>> be sent in NOTIFY messages. In this way, we avoid the increase of 
>>>>> signaling traffic as the number of watchers grows in the case of 
>>>>> Common Notify and as the number of privacy filters grows in the 
>>>>> case of View Sharing.
>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Oct 2008 14:06:12 -0400

I realize that some level of trust is required in each of these cases. 
But at least with view sharing I only trust the domain with data that I 
am willing to give to *some* member of that domain.

For instance, I may have very private info that I only want to share 
with users in my own domain. (This is very common with corporate users.) 
Then there may various degrees of visibility that I will make available 
to users of other domains. View sharing supports that without my having 
to trust all the other domains with my most sensitive data.

With Victoria's proposal, how would you authenticate these other 
domains? Would you allow *all* other domains access to this information? 
  If you have authentication then probably you will want some filter on 
the data that you give to that domain, even if it will enforce policy to 
a finer level.

I guess you could potentially define some domain-wide views that are the 
union of the view given to any subscriber in that domain, and then let 
the server in that domain do the added domain-specific filtering and 
authentication.

	Thanks,
	Paul

Richard Barnes wrote:
>> I don't. At least not in general. (Maybe there are *some* other 
>> domains I would trust to do so.)
>>
>>     Thanks,
>>     Paul
>>
>>> Certainly I considered a mechanism to exchange the policy documents 
>>> of watched presentities between watching and watched domains in 
>>> Common Subscribe solution. The watching domain (RLS) subscribes to an 
>>> event (called “privacy filters”) in presentity domain’s presence 
>>> server. Whenever a change in the policy documents for any of the 
>>> presentity’s watchers happens, a NOTIFY message with “event=privacy 
>>> filters” is sent from presentity’s presence server to watchers’ 
>>> domain. The watching RLS maintains one subscription to “privacy 
>>> filters” event per watched presentity. This subscription could be 
>>> explicit if existing watchers were indicated into the body of 
>>> SUBSCRIBE messages. In this way, when a new watcher is added a 
>>> re-SUBSCRIBE message containing the updated watcher list is sent and 
>>> a NOTIFY message with the policy documents will be received by the 
>>> RLS in response to this resubscription. However, a privacy filters 
>>> subscription could be implicit so that the watcher list is not needed 
>>> in SUBSCRIBE messages, a simple SUBSCRIBE creates a subscription to 
>>> all the existing watchers of the watched presentity. Clearly, a trust 
>>> relationship between watching RLS and watched PS is needed to share 
>>> full-state presence and policy documents of watched presentities.
>>>
>>> privacy filters event). In case of View Sharing, the RLS will 
>>> maintain N*F setting F as the number of different policy documents 
>>> per presentity. At first sight, we can imagine how the performance of 
>>> VS gets worse as F increases.
>>>
>>> privacy rules associated to a presentity happened it would be 
>>> notified as a NOTIFY message into the common subscription between the 
>>> achieves around 50% improvement of presence traffic in the majority 
>>> of cases.
>>>
>>> Regards,
>>>
>>> Victoria
>>>
>>>
>>>> decide whether this is an acceptable security risk or not 
>>>> ("important part of work on the requirements and optimizations will 
>>>> be to make sure that all the security aspects are covered").
>>>>
>>>> "domain-to-domain single subscription" mechanism does not require 
>>>> the complete Presence or Policy documents being exchanged, only 
>>>> those that might be applicable to any user in the watching domain 
>>>> (of course, including a mechanism to update policies, if needed). In 
>>>> they would receive") are applicable to Victoria's proposal, so I 
>>>> fail to see substantial security differences between both 
>>>> approaches. I could envisage potential "logistic" issues, though...
>>>>
>>>> security perspective) between both approaches would be very 
>>>> valuable. In case there are not such differences, the proposed 
>>>> alternative looks interesting, as it seems to represent a very 
>>>> important simplification (in practice, there would be no need to 
>>>> define any SIP extension at all). It is fair to say that a mechanism 
>>>> to exchange policies would need to be defined (not sure is that is 
>>>> covered elsewhere?).
>>>>
>>>> view sharing approach. Even though it leads to larger documents 
>>>> being exchanged (thus containing more Presence information, which is 
>>>>> What about allowed/blocked list that a presentity may have, if 
>>>>> there is a single subscription between watcher domain's presence 
>>>>> server and the watcher presentity.
>>>>>
>>>>>
>>>>>
>>>>>  
>>>>>> between watcher and watched domains, so that the presence server 
>>>>>> in the watcher domain is in charge of subscribing to the watched