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

[David Viamonte <[e-mail]>]

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ó:

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: [e-mail] [mailto:[e-mail]] 
On Behalf Of Victoria Beltrán Martínez
Sent: Wednesday, October 15, 2008 1:11 PM
To: [e-mail]
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.

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
[e-mail]
https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple

    

_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
  

No virus found in this incoming message.
Checked by AVG - http://www.avg.com" rel="nofollow">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
[e-mail]
https://www.ietf.org/mailman/listinfo/simple