Subject: [Simple] Open issue: migration of subscriptions

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 16:51:01 -0400

Folks,

I'd like to begin a thread on another presence open issue that we discussed
at IETF 49.

The issue is with migration of subscriptions. It is discussed in section 6.1
of 
http://www.jdrosen.net/papers/draft-ietf-simple-presence-00.txt. The idea is
that when a subscription refresh arrives, a presence server can destroy the
subscription state, and proxy the request to the PUA, which accepts it
there. The draft indicates that this is problematic for a few reasons:

1. the refresh has to and from tags which don't match an existing
subscription state in the PUA. This means defining special case tag
handling. Tags are awful enough as it is.

2. The route set is already established, and in this route set, the presence
server has inserted the contact. When the presence server acts as a proxy,
it now needs to add itself into the route set with a record-route, and the
contact needs to be updated to be that of the PUA. This kind of route set
update is not possible. Only the contact can change; record-route headers
cannot be added.

Some additional problems:

3. The migration to the PUA is very gradual, taking up to the duration of
the longest subscription refresh interval.

4. It is not clear how to get the subscriptions to migrate back to the
presence server, since the PUA isn't a proxy and can't begin proxying them
there.

I have a proposal on how to fix these problems. The approach is to use our
new friend, the watcherinfo sub-package. Here's how it works.

Lets say A subscribes to B, with the event package presence. Initially,
these subscriptions are handled by the presence server in B's domain, which
acts as a PA. A also subscribes to B using the event package
presence.watcherinfo. B's presence server allows this subscription, but
won't provide A with all information on B's watchers. Rather, A gets
notified only of changes to A's subscription state for B (in other words,
the presence server will, by default, filter the information sent to
subscribers for Bs presence.watcherinfo). At some point, the presence server
decides to migrate the subscriptions to B directly. So, it destroys the
subscriptions for B, which results in a notification to the those subscribed
to presence.watcherinfo for B (which includes A). A will therefore get a
NOTIFY indicating that their subscription is invalidated. A then
re-SUBSCRIBEs, using a brand new Call-ID (i.e., its not a refresh within the
existing call leg, its a totally new one). The presence server proxies these
to B. Since these are brand new subscriptions, they establish a new route
set, which can include the presence server of B on the record-route list. A
also needs to re-SUBSCRIBE to presence.watcherinfo for B, as this too will
now be handled by the B (note that I do not think we need to support A
subscribing to presence.watcherinfo.watcherinfo to determine that its
subsription to presence.watcherinfo for B has been terminated; this can be
implied from the destruction of its presence subscription. Without this, we
have infinite recursion of subscriptions).

Now, at any time, B can also destroy subscription states. This causes
notifications to go to the subcribers of presence.watcherinfo for A. They
can re-SUBSCRIBE once more, and the presence server can terminate them this
time around.

To be specific, here is the call flow:

        | SUB B presence C-ID: 10 |                           |
        |------------------------>|                           |
        | 202 Accepted            |                           |
        |<------------------------|                           |
        |                         |                           |
        | SUB B pres.winfo C-ID 11|                           |
        |------------------------>|                           |
        | 202 Accepted            |                           |
        |<------------------------|                           |
        |                         |                           |
        | NOT A pres.winfo C-ID 11|                           |
        |  sub. invalidated       | server decides            |
        |<------------------------| to migrate subs.          |
        | 200 OK                  |                           |
        |------------------------>|                           |
        | SUB B presence C-ID: 12 |                           |
        |------------------------>| SUB B presence C-ID: 12   |
        |                         |-------------------------->|
        |                         | 202 Accepted              |
        | 202 Accepted            |<--------------------------|
        |<------------------------|                           |
        | SUB B pres.winfo CID: 13|                           |
        |------------------------>| SUB B pres.winfo CID: 13  |
        |                         |-------------------------->|
        |                         | 202 Accepted              |
        | 202 Accepted            |<--------------------------|
        |<------------------------|                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |
        |                         |                           |

       A                         B's                          B
                                 presence
                                 server

I've left off some details, such as the initial NOTIFY after the SUBSCRIBE,
and the authorization. Also, how the presence server decides to migrate the
subscriptions is orthogonal. It could be because B registered support for
the SUBSCRIBE method, or perhaps the user clicked on a web page or
something. Its not shown.

I think this is a fairly clean way to handle migrations, but it introduces
some of the burden for this at the subscriber; namely, when I subscribe to
B, I also need to subscribe to B's presence.watcherinfo to learn the status
of my subscription. Worst case, if this second subscription is not done,
when the first (the normal presence subscription) is refreshed, it generates
a 481 at B's presence server. This can then trigger A to generate a brand
new subscription (with a new Call-ID) which will migrate at that point. This
means we need to additionally specify that a 481 response to a SUBSCRIBE
refresh should cause a new subscription to be made. I think thats
reasonable.

We will also need to somehow allow a SUBSCRIBE to a presence.watcherinfo
package to indicate that the subscription is desired for a particular
watcher only. Not too hard.

Comments?

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: [email-masked]
Date: Tue, 3 Jul 2001 15:39:34 -0500

I like the overall idea, but I see a much easier way to do it.

In draft-roach-sip-subscribe-notify-03, I described a mechanism
by which the notifier can let the subscriber know that the
subscription has been kicked out: send a NOTIFY with an 
"Expires: 0".

This avoids the double subscription, and allows all packages --
even .watcherinfo sub-packages -- to be migrated. If you want
to use such a mechanism, I could add text to support it; essentially,
saying that a "NOTIFY" with an "Expires: 0" should be answered
by an attempt to re-subscribe. If the notifier wanted the subscription
to migrate, it migrates. If the notifier really wanted to kick the
subscriber out, it rejects the SUBSCRIBE it with a 403 or similar.

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 3:51 PM
> To: [email-masked]'
> Subject: [Simple] Open issue: migration of subscriptions
> 
> 
> Folks,
> 
> subscription to presence.watcherinfo for B has been 
> terminated; this can be
> notifications to go to the subscribers of presence.watcherinfo 
> for A. They
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>