Subject: [Simple] Questions on the current presence draft.

From: "Brian Stucker" <[email-masked]>
Date: Tue, 11 Sep 2001 14:29:49 -0500

I was reading through the current draft, and noticed a few things that I 
was looking for clairification on.

In the section on presence migration, the last sentence of the description
for the second phase of presence migration states: "...This informs the
subscribers that their
subscription was destroyed, and should be re-established with a new
SUBSCRIBE (with a new Call-ID)."

I was wondering, if a watcher was offline when the NOTIFY containing the
"Subscription-Expires" header
to destroy the current subscription, what are the implications with the call
id? I would imagine when the
watcher comes back online, and tries to refresh the subscription, it would
use the old call-id (since it doesn't
know that it needs to reselect), which gets proxied to the new PA (after the
migration occurred). This seems like a gap to me.

Also, what happens if the watchers (previous to the migration) never receive
the NOTIFY to update their
subscriptions to cause a refresh. Unless they do a fetch, the new PA doesn't
know that they exist, so their
subscriptions will be effectively moot, but they won't be aware of this
fact. They won't get any notifications, and
won't know that their subscriptions are being ignored.

In section 8, there are mixed uses of the presence URL and SIP URL's. Is
this done intentionally?

Finally, can someone point a link to the draft listed as [4] in the
bibliography? It doesn't seem to be available
at the IETF webpage.

Thanks,

Brian

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Sep 2001 07:28:23 -0400

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Tuesday, September 11, 2001 3:30 PM
To: [email-masked]'
Subject: [Simple] Questions on the current presence draft.

>for the second phase of presence migration states: "...This informs the
subscribers that 
>their 
SUBSCRIBE (with a new 
>Call-ID)." 
"Subscription-
>Expires" header 
>to destroy the current subscription, what are the implications with the
call id? I would 
>imagine when the 
use the old 
>call-id (since it doesn't 
>know that it needs to reselect), which gets proxied to the new PA (after
the migration 
>occurred). This seems like a gap to me.

There are two cases here. In case 1, when the subscriber goes "offline", all
subscriptions state is lost. This would happen when a PC application is
terminated, for example. In that case, when the watcher comes back, it will
have no record of previous subscription state. So, it creates a new
subscription with a brand new call ID. No problems.

In case 2, the subscriber goes "offline" in the sense that its network
connectivity is lost, so it won't get the NOTIFY, but it still retains
subscription state. THis would be the case, for example, with a mobile phone
that goes out of range. When the mobile comes back in range, it will
re-subscribe with the old call-id/route-set, in order to obtain the latest
data it may have missed while out of range. Since this subscribe has a route
set, the request will arrive at the presence server (the one that formerly
owned the subscriptions, but has since migrated them) with the URL of the
presence server in the request URI (like sip:presence-server-1.foo.com).
Since the URL points to itself, the presence server knows that it should
process it. Since no subscriptions exist, this request would be rejected
with a 481. Should it be proxied anyway to the PUA now handling the
subscription, it would probably also be rejected with a 481 because the tags
don't match those of any existing subscriptions at the PUA.

The 481 would trigger the subscriber to retry the subscription with a fresh
call-id and no route set.

The specifications are not clear at the moment about the handling of the
case when you get a subscribe with a tag in the To field that doesn't match
an existing subscription. That needs to be clarified in the events framework
spec. I'll send a note to Adam about it.

>
>Also, what happens if the watchers (previous to the migration) never
receive the NOTIFY to 
>update their 
>subscriptions to cause a refresh. Unless they do a fetch, the new PA
doesn't know that 
>they exist, so their 
fact. They won't 
>get any notifications, and 

I think this is the same problem I discussed above. The question you need to
ask is why the watcher would not have gotten the NOTIFY. Assuming the
watcher application is running the whole time, the only reason this would
occur is a network failure of some sort, or a failure of the presence server
itself. Network failures that occur because the mobile has gone out of range
are generally detectable, and so the mobile can do something about it.
Network failures in the middle of the network which occur for long enough to
prevent a notification from being delivered (in excess of 16s) are hard to
deal with in any protocol. A "nice" presence agent could retain the
subscription state unless it gets a positive response to the NOTIFY, but
that can be used as a DoS attack. So, I don't know how solve this particular
failure case. There will be a gap in the delivery of notifications for the
duration of a refresh period. Given the scope of the failure that must occur
for that to happen, I think thats acceptable. 

Failures of the presence server itself can be handled using traditional
mechanisms, such as replication of subscription state to a hot standby.

>In section 8, there are mixed uses of the presence URL and SIP URL's. Is
this done 
>intentionally? 

No. My error. I've changed them all to sip URLs. Thanks.

>Finally, can someone point a link to the draft listed as [4] in the
bibliography? It 
>doesn't seem to be available 
>at the IETF webpage. 

It just recently expired. The impp chairs have been pinging the editor to
resubmit an update. 

Until then, you can get a copy from google's cached version of the draft:
http://www.google.com/search?q=cache:jdFIIPRBPY0:www.ietf.org/internet-draft
s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=en

Thanks for your 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: "Brian Stucker" <[email-masked]>
Date: Wed, 19 Sep 2001 09:08:51 -0500

Thanks for the clairification.

I'd like to make the problem of the watcher not getting a notification that
their
subscription has expired (due to a migration) because of a temporary failure
at the watcher,
or in the network, go away without a huge hassle if that is possible.

The scenario I'm thinking of would cause problems if the watcher simply
decided to go offline
when the migration occurred. No network failure needed, they just had their
machine turned off
during that time. The problem that I see is that you're right, and you'd
wind up likely creating
a flood of network traffic at some point to recover from this. 

Maybe a note in there somewhere that when a watcher has been SIP unreachable
(powered down, client
software not running, etc.), they need to fetch their subscriptions again
(at a reasonable rate)
in case a migration has occurred?

Thanks,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 6:28 AM
To: Stucker, Brian [NGB:B651:EXCH]; [email-masked]'
Subject: RE: [Simple] Questions on the current presence draft.

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Tuesday, September 11, 2001 3:30 PM
To: [email-masked]'
Subject: [Simple] Questions on the current presence draft.

subscribers that 
SUBSCRIBE (with a new 
"Subscription-
call id? I would 
use the old 
the migration 

receive the NOTIFY to 
doesn't know that 
fact. They won't 

this done 

bibliography? It 

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Sep 2001 17:01:41 -0400

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 10:09 AM
To: Jonathan Rosenberg; [email-masked]'
Subject: RE: [Simple] Questions on the current presence draft.

their 
>subscription has expired (due to a migration) because of a temporary
failure at the 
>watcher, 

Thats generally a good design goal ;)

>The scenario I'm thinking of would cause problems if the watcher simply
decided to go 
>offline 
machine turned
>off 
wind up likely 
>creating 

Why is it a flood? When the watcher comes back, they refresh their
subscriptions. This is just a set of refreshes from one watcher. 

>Maybe a note in there somewhere that when a watcher has been SIP
unreachable (powered down, 
>client 
(at a reasonable 
>rate) 

The problem is easy when the watcher knows they have been unreachable. I'm
not sure anything needs to be said here, as this is not really any different
from basic subscribe. The spec doesn't dictate a system, so I can't rightly
tell people when they have to send SUBSCRIBE; thats the job of the RFP, not
the RFC. 

When a host is SIP unreachable, but doesn't know it, this is quite a hard
problem that affects things far broader than presence, or sip-events even
(what if I miss the BYE, for example, of an ongoing call?). So, I'd rather
not try to address that in this document.

Thanks, 
Brian 

---

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2001 6:28 AM 
To: Stucker, Brian [NGB:B651:EXCH]; [email-masked]' 
Subject: RE: [Simple] Questions on the current presence draft. 

-----Original Message----- 
From: Brian Stucker [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2001 3:30 PM 
To: [email-masked]' 
Subject: [Simple] Questions on the current presence draft. 

subscribers that 
SUBSCRIBE (with a new 
"Subscription- 
call id? I would 
use the old 
the migration 

receive the NOTIFY to 
doesn't know that 
fact. They won't 

this done 
bibliography? It

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 24 Sep 2001 16:33:27 -0500

Thanks Johnathan (er.. Brian, as you signed below), hehe..

I'm just trying to protect from implementations that don't try to actively
keep their subscription state synced. Just seems like relying solely on the
PA to help watchers coordinate their state, without some degree of fetching
by the watcher could cause things to get out of sync in some easy error
scenarios. The flood bit was about the watcher trying to refresh their
subscriptions, and getting 481's back (possibly) a couple of times before
the subscription refreshes correctly. Since it'd be a self-induced flood,
well, I guess that's the problem that the watcher has to deal with, however,
I'm trying to think of ways of protecting the network in this case from
using this as an attack of some sort.

If the watcher gets a 481 back from the presence server because a presence
agent has migrated, how is it to tell that this was because it missed the
subscription expiration, rather than it simply making a bad request on the
presence server?

Thanks,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, September 24, 2001 4:02 PM
To: Stucker, Brian [NGB:B651:EXCH]; Jonathan Rosenberg;
[email-masked]'
Subject: RE: [Simple] Questions on the current presence draft.

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 10:09 AM
To: Jonathan Rosenberg; [email-masked]'
Subject: RE: [Simple] Questions on the current presence draft.

their 
failure at the 

decided to go 
machine turned
wind up likely 

(at a reasonable 

Thanks, 
Brian 

---

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2001 6:28 AM 
To: Stucker, Brian [NGB:B651:EXCH]; [email-masked]' 
Subject: RE: [Simple] Questions on the current presence draft. 

-----Original Message----- 
From: Brian Stucker [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2001 3:30 PM 
To: [email-masked]' 
Subject: [Simple] Questions on the current presence draft. 

subscribers that 
SUBSCRIBE (with a new 
"Subscription- 
call id? I would 
use the old 
the migration 

receive the NOTIFY to 
doesn't know that 
fact. They won't 

this done 
bibliography? It

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 02:16:08 -0400

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Monday, September 24, 2001 5:33 PM
To: Jonathan Rosenberg; Jonathan Rosenberg; [email-masked]'
Subject: RE: [Simple] Questions on the current presence draft.

>I'm just trying to protect from implementations that don't try to actively
keep their 
>subscription state synced. Just seems like relying solely on the PA to help
watchers 
>coordinate their state, without some degree of fetching by the watcher
could cause things 
>to get out of sync in some easy error scenarios.

Subscriptions are soft state, so they should always eventually re-sync.

> The flood bit was about the watcher 
>trying to refresh their subscriptions, and getting 481's back (possibly) a
couple of times 
>before the subscription refreshes correctly. 

Why would it be a couple of times? After the first 481 on a routed/tagged
subscription, it should retry without the Route and tags right away. 

> Since it'd be a self-induced flood, well, I 
>guess that's the problem that the watcher has to deal with, however, I'm
trying to think 
>of ways of protecting the network in this case from using this as an attack
of some sort.

I still don't get it. What flood? Are you worried about the case where the
PA sends a bunch of NOTIFY with Subscription-Expires, causing all the
watchers to resubscribe at the same time? This can be fixed as a local
implementation decision by gradually migrating subscriptions rather than all
at the same time. I'll mention that, but I'm not sure thats what you're
talking about.

>If the watcher gets a 481 back from the presence server because a presence
agent has 
>migrated, how is it to tell that this was because it missed the
subscription expiration, 
>rather than it simply making a bad request on the presence server?

For SUBSCRIBE, 481 should always mean "try again without your tags/Routes
since this doesn't exist where you thought it should". In the case of a PA
that hasn't migrated, but has forgotten its subscription state because it
expired, the refresh shouldn't really generate a 481. Rather, the SUBSCRIBE
should re-establish the subscription state - thats the definition of
soft-state. In this case, the response is a 2xx. The PA would only send a
481 if its not able to reconstruct the subscription state. In that case, the
client does the right thing - tries again without the tags/Routes to rebuild
it from ground zero.

Now, all of this is definitely not clear in sip-events, which is where it
all belongs. I have several emails into Adam to get these things clarified.

-Jonathan R.
---

-----Original Message----- 
From: Brian Stucker [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2001 10:09 AM 
To: Jonathan Rosenberg; [email-masked]' 
Subject: RE: [Simple] Questions on the current presence draft. 

their 
failure at the 
decided to go 

machine turned 
wind up likely 
(at a reasonable 

Thanks, 
Brian 

--- 

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2001 6:28 AM 
To: Stucker, Brian [NGB:B651:EXCH]; [email-masked]' 
Subject: RE: [Simple] Questions on the current presence draft. 

-----Original Message----- 
From: Brian Stucker [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2001 3:30 PM 
To: [email-masked]' 
Subject: [Simple] Questions on the current presence draft. 

subscribers that 
SUBSCRIBE (with a new 
"Subscription- 
call id? I would 
use the old 
the migration 

receive the NOTIFY to 
doesn't know that 
fact. They won't 

this done 
bibliography? It

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 2 Oct 2001 09:21:45 -0500

Replies embedded.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 1:16 AM
To: Stucker, Brian [NGB:B621:EXCH]; Jonathan Rosenberg; Jonathan
Rosenberg; [email-masked]'
Subject: RE: [Simple] Questions on the current presence draft.

trying to think 
of some sort.

*** [Brian S]  Yes, this is what I'm talking about. I think a mention is all
that
it warrants.

agent has 
subscription expiration, 

*** [Brian S] Yes, you are correct. It is. Thanks, Jonathan.