Subject: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions

From: "Nasir Khan" <[email-masked]>
Date: Fri, 1 Jul 2005 18:12:57 -0700

Though I do not have a solution, I think that this is a problem which
will become evident when more and more uses for SIP notification
mechanism come to the fore. 
Arguably there will be cases where the use does not even warrant a SIP
Notification event package.

The vexing problem is the case where the subscriptions have an infinite
life as in a few examples below. 

- "Send me a notification with update to my UA when my user profile
changes" (*which may happen once in months*) {SIP UA Profile framework}
- "Send me a notification when my buddy is in the vicinity of 2 miles"
(*which may not happen in days*) {Presence event package} 
- "Send me notification when the administrator changes my registration
state. (*which may not happen that frequently*) {Registration event
package}

Etc. 
The state that is to be notified in such cases is typically resident in
a database (or some other persistent store), this data is being modified
by different agents, so in above three examples the agents could be 
(a) User changing his own profile going through the self admin website
(b) Presence Server
(c) Registrar Administrator
All this state has nothing to do with dialog semantics, but will result
in unending subscriptions.  

IMHO the "poor man's dialog" is not a bad tradeoff when you have to
maintain these infinitely long subscription dialogs just because a
notification may be generated once in a while. I was trying to think of
a Subscription Server(like a Registrar) with a Subscription data store
(like an abstract location service) and taking the argument further that
Subscription having the capability of sending *out of dialog* NOTIFY
(which is not the same thing as unsolicited NOTIFY when the UA is
*expecting* such NOTIFIES). 

Thanks
Nasir Khan
BEA Systems, Inc. 

>I will second Dale. I think of REGISTER as creating a sort of "poor
man's >dialog". Were we to start over I don't think you would see
REGISTER again >in its current form, but it is grandfathered in now.
>
>Also, the way register works is based on the assumtion that REGISTER
>messages will not be forked to different candidate registrars. If that
did >happen, then register refreshing would not work right. You can't
make the >same assumption about subscriptions, so you need to retain the
route to the >server in order to properly refresh.
>
>I've been having other discussions with people about "implicit
>subscription" or "unsolicited notification". These are all driven by
the >same desire to get rid of some state or the messages that establish
it. For >instance lots of people want to avoid the subscription for MWI.
>
>But as yet nobody has proposed a viable way to do it. Stuff has been
>implemented to do this, but the cases I am aware of are hacks with
major >limitations.
>
>I don't think a solution that requires "some" dyanmic state, but less
that >a dialog, is an interesting solution.
>
>The most interesting case where I think it might be possible to come up
>with a solution is when the notifier knows a priori that it wants to
notify >all registered contacts for its own AoR. In that case the
notifier has >statically provisioned state about its own AoR and the
need to notify that, >but no dynamic state. (The MWI is an example of
this case.) But I haven't >yet found a good solution for even this case.
>
>	Paul
>
>
>Dale Worley wrote:
>
>From: Nasir Khan
>
>
>By stateless notification I mean an entity subscribed to
>certain events
>gets the notifications when the event is generated *without* having to
>maintain any dialog state.
>
>
>
>This seems very difficult to do.  A publisher needs to keep a list of
all
>the subscribers to which it will send notifications.  And since the
>publisher needs to be able to forget a subscription if it is not
refreshed
>after a while, the subscribers need to remember to refresh their
>subscriptions.  Both of these require state.
>
>
>The PUBLISH method avoids these problems, but in effect, by
provisioning the
>list of subscribers rather than constructing it dynamically.
>
>
>Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Avshalom Houri <[email-masked]>
Date: Sat, 2 Jul 2005 21:53:28 +0300

Regarding notifications we can use
PUBLISH the issue is more how we establish

the SLS (State Less SUBSCIRBE).

I am not sure that we need a mechanism
for creating state less subscribes in SIP

or whether this can be done via different
method as XCAP or some web interface

that will store the subscription to
a DB.

Usually state less subscriptions need
to reach the user using any available

method at the time of the notification
(any SIP contact that is available for

the user, email, SMS etc.). So if we
will use SIP for registering those

subscriptions we will need to register
a subscription for the AOR and not

for a specific contact.

BTW: I fully agree with Paul that if
were we to start over again we would not

create REGISTER. We would probably
use only PUB/SUB/NOTIFY

Avshalom Houri

IBM Software Group

"Nasir Khan"
<[email-masked]>

Sent by: [email-masked]

02/07/2005 04:12 AM

To

<[email-masked]>

cc

Subject

[Sip] RE: Stateless Notification and
Non-Subscribe subscriptions

package}

Etc.

(b) Presence Server

IMHO the "poor man's dialog" is not a bad tradeoff when you have
to

Thanks

Nasir Khan

BEA Systems, Inc.

make the >same assumption about subscriptions, so you need to retain
the

it. For >instance lots of people want to avoid the subscription for
MWI.

major >limitations.

Paul

all

refreshed

provisioning the

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 3 Jul 2005 09:15:03 -0700

Nasir,

There is no such thing in the real world of software as an infinite
subscription.  Sometime in the next 5, 10, or 20 years your user agent
will be unplugged, recycled, rebooted, reprogrammed, renumbered or
*something* will happen to it, and unless there is a state recovery
mechanism your notifier will leak memory like a sieve.  For most UAs
it is far more likely for the UA to change IP addresses and therefore
change its Contact address once a week or once a month.

Clearly you need to keep the target URI, an expiration time, and some
indicator of the "version" you are sending so the "subscriber" can
detect stale state.  PUBLISH uses an ETag for this and you can use the
CSeq in a SUB/NOT dialog.

The only additional piece of state left is a Call-ID and two tags
(which I only need for SUB/NOT).  I don't see any convincing analysis
that the Call-ID and tags create such a problem in a real
implementation that actually works (i.e. that is already storing an
expiration time and "version").

It is easy to remove state when you ignore the messy changes that
happen in the real world, but if things didn't change, we wouldn't
have jobs or interesting problems to work on.

thanks,
-rohan

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 5 Jul 2005 11:16:47 -0400

> From: Nasir Khan
>
> The vexing problem is the case where the subscriptions have
> an infinite life as in a few examples below.

Actually, what makes these cases vexing is the extremely low rate at which
notifications will be sent.  One might expect that one could just do a
SUBSCRIBE with a very long expires time, but since NOTIFYs are sent within
the dialog established by SUBSCRIBE, when the UA changes its contact
address, the SUBSCRIBE has to be refreshed.  Hence there is more traffic
maintaining the subscriptions than doing notifications.

So we can characterize the problem as "notifications that are less frequent
than the UA changes its contact address".

Within this context, it seems like PUBLISH messages would be an acceptable
way to deliver the notification.  PUBLISH can be sent to the user's AOR, and
SIP will route the update to the current UA.  (A UA may also have to request
an explicit update when it starts up.)

But how to maintain the state that user foo@bar wants notification of X?  In
practice this is often done by provisioning (foo goes to a web page to
update his list of notifications), because the overhead cost of having an
obsolete notification request in the database is small.  But we might want
to use some variant of SUBSCRIBE to maintain notifications.

Dale

---

From: Dean Willis <[email-masked]>
Date: Thu, 07 Jul 2005 06:21:15 -0500

>to use some variant of SUBSCRIBE to maintain notifications.
I'd like to counter-propose a "subscription aggregator" -- that is, 
allow a single SUBSCRIBE request to establish a dialog upon which 
notifications for multiple event
sources might occur.

One might then define a metapackage that includes, for example, 
subscription to reg-event, mwi, config, presence resource-list, and all 
the other things that a UA might subscribe to on startup.

Jonathan has proposed making REGISTER create a dialog for the servicing 
of subscriptions. I think an aggregator would be much cleaner.

Now, as o how it might work -- the set of subscriptions to be aggregated 
should be defined dynamically. One idea would be to use the body of the 
SUBSCRIBE request to contain a URI list, with each such URI representing 
a resource to be SUBSCRIBEd to. This approach is consistent with the URI 
list work:
see 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-subscribe-03.txt

Another approach would be to use a server-contained list that would be 
modified using XCAP. This is closer to the orignal resource-list work.

--
Dean

---

From: Aki Niemi <[email-masked]>
Date: Thu, 07 Jul 2005 15:57:47 +0300

Inline.

> than the UA changes its contact address".

I agree this is a major deficiency in the SIP events framework. It is 
partly due to the fact that the SUBSCRIBE method is overloaded to do 
initial subscriptions, refreshes, as well as fetches within dialogs. 
Therefore, the notifier will always generate a NOTIFY upon receiving a 
SUBSCRIBE, even though the subscriber may already have that state and 
thus doesn't actually need it.

I think there is a way to solve this, and I'm working on an I-D to lay 
out the problem and start the discussion on possible solutions. 
Hopefully will have it ready before Monday. ;)

> an explicit update when it starts up.)

I don't see much benefit in this. Simply changing the method from a 
dialog creating one to a non-dialog-creating one doesn't solve the 
actual problem of being able to maintain subscriptions with little (or 
no) overhead.

> to use some variant of SUBSCRIBE to maintain notifications.

Right.

Cheers,
Aki

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 7 Jul 2005 09:39:53 -0400

> From: Aki Niemi [mailto:[email-masked]]
>

More exactly, SUBSCRIBE is optimized for the situation where subscriptions
are relatively short lived, and the state they receive changes quite
frequently.  The "dialog state" event package is the sort of thing SUBSCRIBE
works well for.

> actual problem of being able to maintain subscriptions with little (or

In terms of message traffic, replacing SUBSCRIBE with PUBLISH helps a great
deal.  Because SUBSCRIBE maintains a dialog, every time the UA's address
changes, it has to refresh the subscription.  With PUBLISH, those overhead
messages are eliminated, at the cost of increased routing effort for every
notification.

In the end, there's no way to maintain a subscription without maintaining a
record that the subscription exists.  The protocol question is how to
minimize the number of overhead messages.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jul 2005 14:51:21 -0400

> notifications for multiple event

Whether this is useful depends on your goals. THis is a little like an 
RLS on steroids. Like an RLS, it does not in general reduce the total 
amount of work done in the system as a whole - instead it moves the 
place where some of the work is done and also somewhat increases the 
total amount of work done.

It reduces the amount of work that must be done by the watchers. It does 
nothing to the amount of work that must be done by the notifiers. And it 
increases the amount of work that must be done by the "subscription 
aggregator". (From nothing to somewhat more than the total of what would 
otherwise have been done by the watchers.)

But I think one of the goals here is to reduce the load on the servers.

> the other things that a UA might subscribe to on startup.

I thing this would require defining a new event type 
('multiple-events'?), together with the content type used by it. The 
content type would have to be able to embed the notification content for 
any of the aggregated event types.  Not rocket science - definitely 
could be done.

> of subscriptions. I think an aggregator would be much cleaner.

I agree it is "cleaner" in the sense that it doesn't change the 
semantics of anything currently existing. But we will have to agree on 
what our goals are before we can decide what is "better".

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jul 2005 15:16:02 -0400

> messages are eliminated, at the cost of increased routing effort for every

Agree.

> minimize the number of overhead messages.

There is also the issue of minimizing the *amount* of state. For a 
server that already operates on behalf of a particular set of AORs, the 
subscription state can be as small as one bit (publish to the AOR or 
not), up to complete dialog state plus subscription state:
- from tag, to tag, dialog id
- local and remote CSeq
- route set
- local and remote target URI
- event id
- event parameters
- subscription expiration timer
- subscription filters
- ...

	Paul