Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed

From: Byron Campen <[email-masked]>
Date: Thu, 11 Jun 2009 21:32:46 -0500

Going ahead and moving to sipcore, and updating subject line...

	Ok, then I will say that this is a bad idea. I really, really don't  
want to deal with implementors that want to deploy clients that use  
the longest subscription duration possible, and shift the burden of  
keeping the subscription alive to the server through use of the force  
parameter. Because that is exactly what they will do.

Best regards,
Byron Campen

> I would say yes, the intention is to force an update even if nothing
> changed.
>
> Brian
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Byron Campen
>> Sent: Thursday, June 11, 2009 6:00 PM
>> To: sipping
>> Subject: [Sipping] draft-niemi-sipping-event-throttle-08 and forcing
>> notifications when state has not changed
>>
>> 	It appears that the normative language in this draft requires the
>> notifier to send a notification if the force interval has elapsed,  
>> even
>> when state has not changed since the last notification. Reading over
>> some past discussion on list, I got the impression that this was not
>> the intent. So which is it?
>>
>> Best regards,
>> Byron Campen
>

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 12 Jun 2009 11:39:20 -0400

> > I would say yes, the intention is to force an update even if nothing

It does appear that that is the only plausible interpretation of the
'force' parameter.

> parameter. Because that is exactly what they will do.

Could you explicate why this is a bad idea?

As far as I can tell, this scenario of 'force' usage does not place any
additional burden on the notifier, since the notifier would otherwise be
responding to re-subscribe messages, and would be maintaining timers for
the expiration of the subscription.  Indeed, using 'force' would
decrease the message traffic at each quasi-refresh interval to one
NOTIFY/response pair.  (Although a similar effect could be obtained
using re-SUBSCRIBE with etag.)

The risk, it seems to me, is that the notifier would vanish and the
subscriber might continue the subscription for far too long.

Dale

---

From: Byron Campen <[email-masked]>
Date: Fri, 12 Jun 2009 11:02:19 -0500

> It does appear that that is the only plausible interpretation of the

	The general use-case that has been outlined previously is where  
normal notification has been suppressed by filters (or something else,  
maybe event-package-specific); the state has not changed "enough" for  
the subscriber to care about immediate notification. A specific  
example is location data.

> using re-SUBSCRIBE with etag.)

	Indeed, this could be done with etag, and using etag is a far more  
efficient mechanism, because you are not gratuitously sending  
(potentially very large) documents. My main beef is that this shifts  
the job of maintaining soft-state to the server. As a general  
principle, this has been the client's job, and this is specifically  
how SIP events is supposed to work. Allowing the client to say, "Nah,  
you're going to handle recovery now." is a rather fundamental change  
to the protocol, that we should only make if there is a compelling  
reason. I see no such reason.

> subscriber might continue the subscription for far too long.

	Right, that is yet another problem with this.

Best regards,
Byron Campen

---

From: Byron Campen <[email-masked]>
Date: Fri, 12 Jun 2009 11:12:50 -0500

Also, I should note that I see no reason to require these forced  
notifications to contain full state if a partial update is available.

Best regards,
Byron Campen

> normal notification has been suppressed by filters (or something  
> else, maybe event-package-specific); the state has not changed  
> "enough" for the subscriber to care about immediate notification. A  
> specific example is location data.
>
> how SIP events is supposed to work. Allowing the client to say,  
> "Nah, you're going to handle recovery now." is a rather fundamental  
> change to the protocol, that we should only make if there is a  
> compelling reason. I see no such reason.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 12 Jun 2009 12:41:33 -0400

On Fri, 2009-06-12 at 11:02 -0500, Byron Campen wrote:
> My main beef is that this shifts  

I don't understand this.  In my experience, the notifier has to keep
quite a bit of state for a subscription.  The force mechanism only adds
one more timer.

Dale

---

From: Byron Campen <[email-masked]>
Date: Fri, 12 Jun 2009 12:25:45 -0500

> quite a bit of state for a subscription.  The force mechanism only  

	The subscription itself was the soft-state I was referring to; the  
whole idea is that, if the client stops maintaining it, it goes away  
in a reasonable amount of time. I worry that this will be circumvented  
by implementors through the force mechanism.

Best regards,
Byron Campen

---

From: Byron Campen <[email-masked]>
Date: Fri, 12 Jun 2009 12:44:32 -0500

> quite a bit of state for a subscription.  The force mechanism only  

	I also should have noted that I don't object to there being a force  
mechanism at all; I only object to it forcing notifications to be sent  
when the state is exactly the same as the last NOTIFY (I also object  
to it forcing a full-state notification; if the client wants full  
state, it should send a SUBSCRIBE). If you have mechanisms that can  
suppress notifications, a force mechanism is a nice thing to have. I  
just see no value in having doubly gratuitous full-state notifications.

Best regards,
Byron Campen

---

From: Dean Willis <[email-masked]>
Date: Sat, 13 Jun 2009 13:51:11 -0500

Byron Campen wrote:

> (potentially very large) documents. My main beef is that this shifts the
> job of maintaining soft-state to the server. As a general principle,
> this has been the client's job, and this is specifically how SIP events
> is supposed to work. Allowing the client to say, "Nah, you're going to
> handle recovery now." is a rather fundamental change to the protocol,
> that we should only make if there is a compelling reason. I see no such
> reason.
> 

I find this argument compelling. It might even be worth expounding on
this general concept in rfrc265bis.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 13 Jun 2009 16:39:30 -0400

I definitely agree with this as an argument against using rate limiting 
as a form of "session-timer for subscriptions".

I never had the sense that the minimum rate "limit" was being proposed 
for that purpose. (I have never been able to make any sense for why that 
was being proposed, but I just decided there was no point in arguing 
against it just because it made no sense.)

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 15 Jun 2009 16:07:32 +0300

Hi there,

the original idea behind the force mechanism, is that there could be 
situation where the client needs to receive periodically, whenever the 
time since the most recent notification exceeds
a specified value, a full NOTIFY. That is especially true for subscriber 
implementations that choose to operate in semi-stateless mode, in which 
they immediately upon receiving and processing the NOTIFY forget the 
resource state.

In general etags mechanism work well for :
- an event package that generates few state changes, and is refreshed 
relatively often the majority of traffic generated may be related to 
subscription maintenance.
-fetching and polling of resource state

but I don't think it could work in general, I mean in a long Subscribe 
that does not generate few state changes.

best regards
Sal

Byron Campen wrote:
> <snip>

> ------------------------------------------------------------------------
>

---

From: Byron Campen <[email-masked]>
Date: Mon, 15 Jun 2009 09:02:08 -0500

This is what refresh SUBSCRIBEs are for.

Best regards,
Byron Campen

> situation where the client needs to receive periodically, whenever  
> the time since the most recent notification exceeds
> a specified value, a full NOTIFY. That is especially true for  
> subscriber implementations that choose to operate in semi-stateless  
> mode, in which they immediately upon receiving and processing the  
> NOTIFY forget the resource state.
>
> - an event package that generates few state changes, and is  
> refreshed relatively often the majority of traffic generated may be  
> related to subscription maintenance.
> but I don't think it could work in general, I mean in a long  
> Subscribe that does not generate few state changes.
>
> best regards
> Sal
>
> Byron Campen wrote:
>> <snip>
>
>>   I also should have noted that I don't object to there being a  
>> force mechanism at all; I only object to it forcing notifications  
>> to be sent when the state is exactly the same as the last NOTIFY (I  
>> also object to it forcing a full-state notification; if the client  
>> wants full state, it should send a SUBSCRIBE). If you have  
>> mechanisms that can suppress notifications, a force mechanism is a  
>> nice thing to have. I just see no value in having doubly gratuitous  
>> full-state notifications.
>>
>> Best regards,
>> Byron Campen
>>