Re: [Simple] Other proposal from View Sharing and Common Notify to reduce presence traffic
Victoria Beltrán Martínez <vbeltran@entel.upc.edu> Fri, 17 October 2008 17:13 UTC
Return-Path: <simple-bounces@ietf.org>
X-Original-To: simple-archive@megatron.ietf.org
Delivered-To: ietfarch-simple-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18443A6936; Fri, 17 Oct 2008 10:13:17 -0700 (PDT)
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407613A67EA for <simple@core3.amsl.com>; Fri, 17 Oct 2008 10:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHlHNQTWWFI4 for <simple@core3.amsl.com>; Fri, 17 Oct 2008 10:13:15 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by core3.amsl.com (Postfix) with ESMTP id 3A5BA3A6A1E for <simple@ietf.org>; Fri, 17 Oct 2008 10:13:15 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id m9HHDjtV009210; Fri, 17 Oct 2008 19:13:45 +0200
Received: from [147.83.47.151] (c5s102-151.upc.es [147.83.47.151]) by entelserver.upc.edu (Postfix) with ESMTP id ADB552CBD01; Fri, 17 Oct 2008 19:13:40 +0200 (CEST)
Message-ID: <48F8C7C1.2070302@entel.upc.es>
Date: Fri, 17 Oct 2008 19:13:37 +0200
From: Victoria Beltrán Martínez <vbeltran@entel.upc.edu>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: David Viamonte <david.viamonte@genaker.net>
References: <C7FFFFDD779F2047A0FBAC811C5C5A0006F86A83@xmb-rtp-201.amer.cisco.com> <48F7F17F.3010900@genaker.net>
In-Reply-To: <48F7F17F.3010900@genaker.net>
X-Mail-Scanned: Criba 2.0 + Clamd
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Fri, 17 Oct 2008 19:13:47 +0200 (CEST)
Cc: simple@ietf.org
Subject: Re: [Simple] Other proposal from View Sharing and Common Notify to reduce presence traffic
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
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: > 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: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] >>> On Behalf Of Victoria Beltrán Martínez >>> Sent: Wednesday, October 15, 2008 1:11 PM >>> To: simple@ietf.org >>> 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 >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> >> ------------------------------------------------------------------------ >> >> >> 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 Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple
- [Simple] Other proposal from View Sharing and Com… Victoria Beltrán Martínez
- Re: [Simple] Other proposal from View Sharing and… Sanjay Sinha (sanjsinh)
- Re: [Simple] Other proposal from View Sharing and… David Viamonte
- Re: [Simple] Other proposal from View Sharing and… Victoria Beltrán Martínez
- Re: [Simple] Other proposal from View Sharing and… Paul Kyzivat
- Re: [Simple] Other proposal from View Sharing and… Richard Barnes
- Re: [Simple] Other proposal from View Sharing and… Paul Kyzivat
- Re: [Simple] Other proposal from View Sharing and… Jonathan Rosenberg
- Re: [Simple] Other proposal from View Sharing and… Avshalom Houri
- Re: [Simple] Other proposal from View Sharing and… david.viamonte
- Re: [Simple] Other proposal from View Sharing and… Avshalom Houri