Subject: [Simple] FW: I-D Action:draft-rosen-simple-watcher-count-00.txt

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Feb 2008 08:32:38 -0500

Please take a look at this draft.  The authors would appreciate your
comments.  

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Monday, February 18, 2008 3:30 PM
> To: [email-masked]
> Subject: I-D Action:draft-rosen-simple-watcher-count-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : Optimizing Notifications for Presence Network
> Agents
> 	Author(s)       : B. Rosen, et al.
> 	Filename        : draft-rosen-simple-watcher-count-00.txt
> 	Pages           : 19
> 	Date            : 2008-02-18
> 
> In large presence systems deployed in multiservice networks, presence
> information is often known by the network in addition to, or instead
> of the presentity's devices (endpoints).  Examples of such
> information include location and availability for various kinds of
> session establishment.  Even if devices know the information, the
> network often has more bandwidth and better scale to keep the
> presence server up to date.  A Presence Network Agent (PNA) can
> publish presence information to a Presence Server(PS).  When done
> large scale, the basic publish operation can be inefficient.  When
> the network has millions of subscribers, only some of which have
> watchers, blind Publish operations are unecessary.  WINFO can be used
> to determine watchers, but the efficiency of maintaining WINFO per
> subscriber, and the size of the messages involved, make that solution
> unattractive.  The PNA would prefer to have the Presence Server
> simply tell it when there was at least one watcher.
> 
> This document describes an XML document stored on the PS by which the
> PNA maintains a list of subscribers it can provide presence for as a
> SIP event package that tells the PNA when the number of watchers for
> a presentity on the list (or a specific presence element for a
> presentity) goes from 0 to at least 1 or from 1 to 0.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-rosen-simple-watcher-count-
> 00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> 	"get draft-rosen-simple-watcher-count-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-rosen-simple-watcher-count-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
ENCODING mime
FILE /internet-drafts/draft-rosen-simple-watcher-count-00.txt
_______________________________________________
Simple mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Feb 2008 22:24:11 -0500

If I understand this correctly, there are two problems you are trying to 
address, and there are two pretty separate mechanisms in here:

1. how does the PNA know which presentities to publish for, and this is 
solved by having the PNA subscribe to the new event package, and

2. how does the PS know which presentities are served by a particular 
PNA, and that is what the xcap usage is for

is that right?

It seems to me that an alternative way to handle #1 is a subscription. 
When the number if watchers for a presentity on the PS goes above zero, 
the PS SUBSCRIBEs to the PNA for that presentity (basically a back-end 
subscription). When it goes back to zero, it unsubscribes. To avoid 
having N subscriptions, one for each active presentity, it'd be ideal to 
have a single subscription with something like Uri-list services. In 
other words, there is one subscription and one dialog, and the list of 
URI to subscribe to is provided in the body of the SUBSCRIBE. We have 
specs for that today (draft-ietf-sip-uri-list-subscribe). The only 
problem is that spec doesn't allow you to change the list over time. We 
need that here. Including a delta in SUBSCRIBE refreshes is an easy 
solution, and hinted at in that spec.

There are a LOT of cases where one server is interested in the state of 
a whole lot of URIs, the set of which changes over time. Having an 
optimized way to do this with a single subscription usng 
uri-list-subscribe is, I think, a more general solution that would be 
really valuable.

The second problem is really a ROUTING problem. How do I find the server 
in my domain that has information on a particular event package for a 
particular user? There are lots of variations on this problem that all 
look the same. See draft-ietf-simple-intradomain-federation for another 
case - how do I find the one (of many) presence servers in my domain 
that serve the presence event package for a particular user? All of the 
mechanisms defined in that document for routing could be used here too - 
its the same problem. Your xcap proposal is basically using a central DB 
and writing it with xcap. I think it'd be worth exploring this problem 
space more generally.

-Jonathan R.

Brian Rosen wrote:
>> ------------------------------------------------------------------------
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 28 Feb 2008 21:10:10 -0500

The authors have discussed having the list in the subscribe, and the delta
problem was the reason we left it as an XCAP managed document.  I think we'd
be amenable to exploring a more general solution.

I'm generally am in favor of more general purpose mechanisms, and I agree
that the general problem of knowing changing state of a set of URIs is a
general problem.  Of course, you never know for any particular problem if a
focused point solution really is better than a more general solution.  The
authors presented a point solution as a conversation starter, but I think
again we would be amenable to a more general purpose mechanism if that was
the consensus in the WG.  It probably generalizes beyond SIMPLE, but I
suspect we can keep the discussion going here for the time being.

We would like to keep the property that all it takes is one transaction for
the PS to tell the PNA about any changes that have happened (as opposed to
transaction per presentity), but I think we're pretty open on the semantics
of what the operation was doing.

I should also mention that we would even like to generalize the mechanism we
have proposed in a different dimension: a PNA may publish a number of
elements and would actually like to know if there are watchers for a
particular element rather than just the over-all watcher count.  The more
general the basic mechanism, the more realistic that kind of extension
should be.

Brian

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2008 10:24 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: [Simple] FW: I-D Action:draft-rosen-simple-watcher-count-
> 00.txt
>