Subject: [Sipping] Re: New draft discussing SIP events issues

From: Aki Niemi <[email-masked]>
Date: Mon, 11 Jul 2005 17:42:13 +0300

[moved over to SIPPING, since that's where the draft is]

Hi Paul,

Comments inline.

ext Paul Kyzivat wrote:
>>    In certain conditions, the overhead induced by having to maintain
>>    subscriptions becomes prohibitively high for subscribers. 
> 
> 
> Not just subscribers. Notifiers too.

Yes, true.

> I find it interesting to see what you chose to include and omit as 
> requirements. My reaction is that I think there need to be more 
> requirements. That may mean that there will need to be a range of 
> different behaviors in order to satisfy everyone.

Perhaps there needs to be more. These were in my opinion the core 
requirements, as they relate to the problems I'm describing.

> In general I would characterize what I hear as a desire to minimize some 
> metric over the system that includes the "subscribers", "publishers", 
> and any intermediaries. The optimization may include some or all of the 
> elements in the system. (E.g. state storage in subscribers may not be 
> important.)
> 
> The following are a couple that I have heard expressed one way or another:
> 
> - "subscriber" doesn't want to subscribe at all, or maintain any
>   subscription state. Would rather just handle "notifications"
>   as context free events. Expects notifications to be delivered to
>   it as result of external configuration that it has no involvement
>   with.

Right, RFC 3265 actually talks about this. It says that there may be 
other ways to install subscriptions than the SUBSCRIBE method. I also 
have an open issue that lists this as one alternative option.

However, I chose to look at things from the current RFC 3265 POW. In 
other words, I want to improve the efficiency of the subscription 
maintenance using SUBSCRIBE, not replace it with a hard-state alternative.

I believe the current mechanisms for subscription maintenance have some 
deficiencies that cause problems in wide-scale deployments, especially 
over mobile networks. There are simply too many superfluous 
notifications being sent. But the model is still an atractive one, and i 
also believe the deficiencies can be removed using the mechanisms I 
describe in the draft.

> - "notifier" doesn't want to maintain any state about those interested
>   it. It prefers to just "publish" interesting info about itself to
>   one place. (Note that this can be achieved by publishing to an
>   event state agent which carries the rest of the load.)

Right, and this is the design many event packages promote by default. 
Presence and certs to name a couple rely on a network based node to 
handle the subscription and notification, and choose to have the end 
nodes do simple PUBLISHing to this network based node.

Cheers,
Aki

>     Paul
> 
> Aki Niemi wrote:
> 
>> All,
>>
>> I've submitted a new I-D that discusses in detail some of the issues 
>> that have also come up in this thread, as well as proposes some 
>> potential solutions. Until it appears in the archives, you can fetch a 
>> copy at:
>>
>> http://people.nokia.net/~aki/drafts/draft-niemi-sipping-subnot-issues-00.txt 
>>
>>
>> Also: please direct discussion of the draft over to SIPPING, as I 
>> think it belongs there more than in SIP.
>>
>> Cheers,
>> Aki
>>
>>
>> _______________________________________________
>> 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
>>
> 
> _______________________________________________
> 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
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jul 2005 14:35:50 -0400

Aki Niemi wrote:
>> In general I would characterize what I hear as a desire to minimize 
>> some metric over the system that includes the "subscribers", 
>> "publishers", and any intermediaries. The optimization may include 
>> some or all of the elements in the system. (E.g. state storage in 
>> subscribers may not be important.)
>>

While 3265 isn't very explicit about this, I think it does intend that 
subscriptions installed by means other than SBUSCRIBE are still 
contracts between the two parties - where both are aware they have 
entered into the contract. So I don't think it applies to cases where 
the recipient of the notifies is not aware of any subscription. So I 
don't think it applies to the cases I am highlighting here.

> maintenance using SUBSCRIBE, not replace it with a hard-state alternative.

Like I said, I think there are a multiplicity of views on what the goal is.

> nodes do simple PUBLISHing to this network based node.

If this (state agent) model is widely used, and if many event packages 
are routed through the same state agent for a given watcher, then it 
starts to be attractive to look at a way to establish a single 
subscription between the watcher and the state agent for delivery of all 
the kinds of events that the state agent handles. Dean made a proposal 
for something like that.

	Paul

>>> potential solutions. Until it appears in the archives, you can fetch 
>>> a copy at:
>>>

---

From: Aki Niemi <[email-masked]>
Date: Tue, 12 Jul 2005 16:06:14 +0300

> don't think it applies to the cases I am highlighting here.

Ok, then I think we are talking about other types of events than what 
are currently defined. Or at least different from the ones whose 
performance I was trying to improve.

> Like I said, I think there are a multiplicity of views on what the goal is.

I completely agree that there may even be multiple goals in solving 
multiple problems. My goal is to make SUBSCRIBE behave better.

> the kinds of events that the state agent handles. Dean made a proposal 

There already exists a mechanism to multiplex many subscriptions into a 
single dialog using the "id" attribute. It actually isn't clear whether 
that only applies to subscriptions to a single event package only.

Otherwise, the idea as such is interesting. It isn't what I was looking 
for though, and I think there are some problems if a set of 
subscriptions need to be installed in a single pass.

Which event state gets sent to a refresh SUBSCRIBE - all of it? If 
default expirations differ by far (say from minutes to days) is it wise 
to use a single subscription to maintain both of them? How likely is it, 
that a single agent is responsible for all packages?

Cheers,
Aki