Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Aug 2008 17:53:36 -0400

It works, it's just too much signaling.  It's also hard for the watcher to
know when to switch.

I really think min is s simpler mechanism.

I've been talking to the throttle authors.  I'll have a proposal on the list
shortly.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, July 31, 2008 10:22 PM
> To: Brian Rosen
> Cc: 'sipping'
> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
> 
> 
> 
> Brian Rosen wrote:
> > I agree: we could instantiate two independent subscriptions, with two
> > independent filters, two throttles, etc, and get what we want.
> >
> > We could also have a min throttle option.
> 
> That isn't what I meant.
> Start the subscription with one filter and one throttle.
> When that isn't what you want any longer, change it to a different
> filter and a different throttle.
> 
> AFAICT you don't need both settings at the same time.
> 
> 	Paul
> 
> 
> > Brian
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[email-masked]]
> >> Sent: Thursday, July 31, 2008 12:36 PM
> >> To: Brian Rosen
> >> Cc: 'sipping'
> >> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-
> 06
> >>
> >>
> >>
> >> Brian Rosen wrote:
> >>> This really is pretty easy.  You are tracking an object.  You want to
> >> filter
> >>> the notifications.  If the target is moving rapidly (large changes),
> you
> >> can
> >>> tolerate 10 updates a minute.  If the target is moving slowly, you
> don't
> >>> want to be bothered (because it isn't changing much), but, at least
> once
> >> in
> >>> a while, you want to update the location.
> >>>
> >>> If you set the update rate to be the same, but a very small motion
> >> change
> >>> spec, you will nearly always get a high rate of change.  That's not
> >>> interesting (it's why you set the change limit high in the first
> place).
> >>> However, you also want to get, eventually, the smaller changes.
> >>>
> >>> You can think of this as the way your eyes work: they have a filter
> for
> >>> rapid change, and you can follow that motion.  When you are doing
> that,
> >> you
> >>> don't notice small changes.  If the object stops moving, you engage a
> >>> different part of the brain, and it's more sensitive to small changes.
> >>> However, if you get a lot of small changes, you perceive that as blur.
> >>
> >> What you describe is entirely consistent with having two
> filter/throttle
> >> combinations and switching between them. The switch can be because you
> >> are getting close and need the more detailed information, or simply
> >> because you are getting no updates at the course granularity.
> >>
> >> It doesn't require a minimum rate on the throttle.
> >>
> >> 	Paul
> >>
> >>> Brian
> >>>
> >>>> -----Original Message-----
> >>>> From: Paul Kyzivat [mailto:[email-masked]]
> >>>> Sent: Thursday, July 31, 2008 11:01 AM
> >>>> To: Brian Rosen
> >>>> Cc: Rosen, Brian; 'sipping'
> >>>> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-
> throttle-
> >> 06
> >>>>
> >>>>
> >>>> Brian Rosen wrote:
> >>>>> Having thought about, and discussed the idea of multiple filters, it
> >>>> won't
> >>>>> work.  We would need multiple subscriptions to get "update when
> target
> >>>> moves
> >>>>> every 10 meters, no more than 10 per minute, but tell me where the
> >>>> target is
> >>>>> if it moves at all at least once a minute"
> >>>>>
> >>>>> You need one subscription with a min move of 10 meters and a
> throttle
> >> of
> >>>> 6
> >>>>> seconds, and another with a min move of 1 cm and a throttle of 60
> >>>> seconds.
> >>>>> Not good.
> >>>> There is something wrong with that requirement - I'm trying to figure
> >>>> out what it is.
> >>>>
> >>>> If you are willing to get notifications every 6 seconds for big
> moves,
> >>>> then why aren't you willing to take notifications every 6 seconds for
> >>>> small moves?
> >>>>
> >>>> I gather this must just be a cost/benefit tradeoff: the benefit of
> >>>> knowing about a big move is worth the cost of frequent notifications,
> >>>> but the benefit of knowing about small moves is less, and so isn't
> >> worth
> >>>> so high a price. Is that right?
> >>>>
> >>>> Maybe its not that you need two filters and throttles simultaneously
> -
> >>>> rather than you need them in different contexts. When you are
> >>>> dispatching the ambulance, you need the coarse location. If the
> target
> >>>> is moving rapidly, you may have to chase them, or dispatch a
> different
> >>>> ambulance, etc. But when the workers finally arrive at the coarse
> >>>> location, then you need a fine location to direct them to the target.
> >> So
> >>>> at that point you could switch to a different filter and throttle.
> >>>>
> >>>> The minimum just doesn't make any sense to me.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul
> >>>>
> >>>>> So, I'm back to needing min, recognizing that it's not a direct
> answer
> >>>> to
> >>>>> the actual problem, but a perfectly acceptable mechanism that
> >>>> accomplishes
> >>>>> the goal.
> >>>>>
> >>>>> Several of us had a meeting today at IETF where this was discussed,
> >> and
> >>>> a
> >>>>> change to throttle that does a couple of things for us looks
> possible.
> >>>>>
> >>>>> Brian
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Rosen, Brian [mailto:[email-masked]]
> >>>>>> Sent: Tuesday, July 29, 2008 11:42 AM
> >>>>>> To: Paul Kyzivat; Brian Rosen
> >>>>>> Cc: sipping
> >>>>>> Subject: RE: [Sipping] Comments on draft-niemi-sipping-event-
> >> throttle-
> >>>> 06
> >>>>>> Ah, I get it.
> >>>>>>
> >>>>>> Hmmm.  Okay, the requirement is some way to catch small changes.
> >>>>>> So, maybe we need a series of filters.  A min rate is so much
> simpler
> >>>>>> than that :)
> >>>>>>
> >>>>>> Brian
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Paul Kyzivat [mailto:[email-masked]]
> >>>>>>> Sent: Tuesday, July 29, 2008 10:04 AM
> >>>>>>> To: Brian Rosen
> >>>>>>> Cc: Rosen, Brian; 'sipping'
> >>>>>>> Subject: Re: [Sipping] Comments on
> >>>>>> draft-niemi-sipping-event-throttle-06
> >>>>>>> Brian Rosen wrote:
> >>>>>>>> No, it's not a keep alive.
> >>>>>>>>
> >>>>>>>> If the target moves by less than 10 meters, it moves, but we
> don't
> >>>>>> know.
> >>>>>>> We
> >>>>>>>> need to know.  The "at least 10 meters, no more than 10
> >> updates/sec"
> >>>>>> is
> >>>>>>> all
> >>>>>>>> a rate limit.  If the target moves a little, slowly, we get slow
> >>>>>>> updates.
> >>>>>>>
> >>>>>>> But if the target doesn't move at all (to the limits of its
> ability
> >> to
> >>>>>>> detect) then you don't need an update??? Its been my impression
> from
> >>>>>>> this discussion that you were requesting unconditional
> notifications
> >>>>>> of
> >>>>>>> location at some minimum frequency.
> >>>>>>>
> >>>>>>> Its significant for the large population of devices that have a
> >> fixed
> >>>>>>> location.
> >>>>>>>
> >>>>>>> 	Paul
> >>>>>>>
> >>>>>>>> Brian
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: [email-masked] [mailto:[email-masked]]
> >> On
> >>>>>>> Behalf
> >>>>>>>>> Of Paul Kyzivat
> >>>>>>>>> Sent: Tuesday, July 29, 2008 9:32 AM
> >>>>>>>>> To: Rosen, Brian
> >>>>>>>>> Cc: sipping
> >>>>>>>>> Subject: Re: [Sipping] Comments on
> >>>>>> draft-niemi-sipping-event-throttle-
> >>>>>>> 06
> >>>>>>>>> WHY is it necessary to get a notification of location even if
> the
> >>>>>>>>> location has not changed?
> >>>>>>>>>
> >>>>>>>>> Is this just a keep-alive? If so, why not address the need for a
> >>>>>>>>> keep-alive instead of imposing a requirement for location?
> >>>>>>>>>
> >>>>>>>>> Keep-alives can be handled via session timer.
> >>>>>>>>>
> >>>>>>>>> 	Paul
> >>>>>>>>>
> >>>>>>>>> Rosen, Brian wrote:
> >>>>>>>>>> It was suggested in geopriv that -throttle be used to control
> the
> >>>>>> rate
> >>>>>>>>>> at which notifications are sent when a watcher is tracking a
> >>>>>> moving
> >>>>>>>>>> target.  This may be a reasonable way to do it, but I have two
> >>>>>>>>>> observations about the current throttle draft relative to use
> >> with
> >>>>>>>>>> location.
> >>>>>>>>>>
> >>>>>>>>>> First, we need a minimum rate (or maximum time) for
> >> notifications.
> >>>>>> In
> >>>>>>>>>> location, we may wish to have a rate limit that is something
> like
> >>>>>>> "send
> >>>>>>>>>> me an update when the target has moved at least 10 meters, but
> >>>>>> don't
> >>>>>>>>>> send more than 10 updates per second.  Also, if the target
> hasn't
> >>>>>>> moved
> >>>>>>>>>> more than 10 meters in a second, send me an update anyway".
> This
> >>>>>>>>>> implies a maximum time as well as a minimum time for the
> >> throttle.
> >>>>>>> I'm
> >>>>>>>>>> not sure if there are other uses for a maximum time, but we
> would
> >>>>>> need
> >>>>>>>>>> one for location.
> >>>>>>>>>>
> >>>>>>>>>> Secondly, I observe that there are two ways to control event
> >>>>>>>>>> notification.  One way is expressed in the current draft, which
> >> is
> >>>>>> a
> >>>>>>>>>> minimum time in seconds between notifications.  Another way to
> >>>>>> express
> >>>>>>>>>> rate is an average over a time period.  The former is an
> >>>>>> instantaneous
> >>>>>>>>>> limit, the latter is a longer term average.  For this purpose,
> I
> >>>>>> think
> >>>>>>> a
> >>>>>>>>>> simple running average would be good enough, so we would not
> need
> >>>>>> to
> >>>>>>>>>> keep much history state.  I think most applications are better
> >>>>>> served
> >>>>>>> by
> >>>>>>>>>> averaging rather than instantaneous limits.
> >>>>>>>>>>
> >>>>>>>>>> Brian
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Sipping mailing list
> >>>>>> https://www.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
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Sipping mailing list
> >> https://www.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
> >>>>>>>> _______________________________________________
> >>>>>>>> Sipping mailing list
> https://www.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
> >>>>>>>>
> >>>>> _______________________________________________
> >>>>> Sipping mailing list  https://www.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
> >>>>>
> >>>
> >
> > _______________________________________________
> > Sipping mailing list  https://www.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
> >

_______________________________________________
Sipping mailing list  https://www.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: Fri, 01 Aug 2008 18:45:02 -0400

> I've been talking to the throttle authors.  I'll have a proposal on the list

I hear you. I understand it is simpler. But I just have trouble making 
any *sense* semantically out of a minimum frequency for a throttle.

I certainly hope it won't have you sending *identical* data when nothing 
has changed since the last send.

	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 07 Aug 2008 18:23:34 +0300

Hi Paul,

just to clarify,
with the *max=X* you are asking not to receive more then a Notify every 
X seconds, no matter what will happen during the X seconds
with the *mix=Y* you are asking to receive an update, if something has 
changed, every Y second. So if you won't receive anything after Y second
you can relay on the fact that nothing is changed .

Sal

Paul Kyzivat wrote:
> I certainly hope it won't have you sending *identical* data when 
> nothing has changed since the last send.
>
> Paul
>
>> Brian
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Aug 2008 12:20:08 -0400

> you can relay on the fact that nothing is changed .

OK, at least you aren't proposing to send every Y seconds even if 
nothing has changed!

But what is the difference between the min present and the min absent? 
What you describe sounds like what would happen anyway - when there is a 
change, you get notified.

Of course the notifier will always have some latency, and so may not get 
around to sending for awhile. But I don't think you can legislate that away.

Or are you saying that you will receive a notification after Y seconds 
if the event state has changed, even if the result after applying 
filters is unchanged???

	Paul

---

From: <[email-masked]>
Date: Fri, 8 Aug 2008 18:03:37 -0500

Hi Paul et al,

>Or are you saying that you will receive a notification after Y 
>seconds if the event state has changed, even if the result 
>after applying filters is unchanged???

That is exactly the idea. If you look at the use case Brian described
as...
"send me an update when the target has moved at least 10 meters, but
don't send more than 10 updates per minute.  Also, if the target hasn't
moved more than 10 meters in a minute, send me an update anyway" you
would get a NOTIFY if the target moved 9 meters and one minute already
passed from the last notification.
I also prefer this approach (adding a "min" value to throttle) instead
of letting the watcher constantly monitor whether the supplied filter is
still satisfactory and re-SUBSCRIBE with new filter if needed. The
watcher could still do that in some cases but in most cases enough
NOTIFYs could be received thanks to the "min" value.

During the discussion with Brian, Salvatore and Adam we also discussed
adding an average rate as a 3rd parameter to throttle.  Some
applications may need that in addition to minimum time between
notifications. We need some kind averaging algorithm, nothing really
complex but a simple running average. It would be good to extend the
discussion also about this parameter and get the WG's feedback.

Cheers,
Krisztian

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Paul Kyzivat
>Sent: Thursday, August 07, 2008 9:20 AM
>To: Salvatore Loreto
>Cc: 'sipping'
>> with the *max=X* you are asking not to receive more then a Notify 
>> every X seconds, no matter what will happen during the X 
>seconds with 
>> the *mix=Y* you are asking to receive an update, if something has 
>> changed, every Y second. So if you won't receive anything after Y 
>> second you can relay on the fact that nothing is changed .
>
>OK, at least you aren't proposing to send every Y seconds even 
>if nothing has changed!
>
>What you describe sounds like what would happen anyway - when 
>there is a change, you get notified.
>
>Of course the notifier will always have some latency, and so 
>may not get around to sending for awhile. But I don't think 
>you can legislate that away.
>
>Or are you saying that you will receive a notification after Y 
>seconds if the event state has changed, even if the result 
>after applying filters is unchanged???
>
>	Paul
>
>> Sal
>> 
>> 
>> Paul Kyzivat wrote:
>>>
>>>
>>> Brian Rosen wrote:
>>>> It works, it's just too much signaling. It's also hard for the 
>>>> watcher to know when to switch.
>>>>
>>>> I've been talking to the throttle authors. I'll have a proposal on 
>>>> the list shortly.
>>>
>>> I hear you. I understand it is simpler. But I just have trouble 
>>> making any *sense* semantically out of a minimum frequency 
>for a throttle.
>>>
>>>>>> I agree: we could instantiate two independent 
>subscriptions, with 
>>>>>> two independent filters, two throttles, etc, and get 
>what we want.
>>>>>>
>>>>>>>> This really is pretty easy. You are tracking an 
>object. You want 
>>>>>>>> to
>>>>>>> filter
>>>>>>>> spec, you will nearly always get a high rate of change. That's 
>>>>>>>> not interesting (it's why you set the change limit high in the 
>>>>>>>> first
>>>>> place).
>>>>>>>> don't notice small changes. If the object stops moving, you 
>>>>>>>> engage a different part of the brain, and it's more 
>sensitive to 
>>>>>>>> small changes.
>>>>>>>> However, if you get a lot of small changes, you 
>perceive that as 
>>>>>>>> blur.
>>>>>>> combinations and switching between them. The switch can be 
>>>>>>> because you are getting close and need the more detailed 
>>>>>>> information, or simply because you are getting no 
>updates at the 
>>>>>>> course granularity.
>>>>>>>
>>>>>>>>>> every 10 meters, no more than 10 per minute, but 
>tell me where 
>>>>>>>>>> the
>>>>>>>>> target is
>>>>>>>>>> seconds, and another with a min move of 1 cm and a 
>throttle of 
>>>>>>>>>> 60
>>>>>>>>> seconds.
>>>>>>>>>> Not good.
>>>>>>>>> There is something wrong with that requirement - I'm 
>trying to 
>>>>>>>>> figure out what it is.
>>>>>>>>>
>>>>>>>>> then why aren't you willing to take notifications every 6 
>>>>>>>>> seconds for small moves?
>>>>>>>>>
>>>>>>>>> I gather this must just be a cost/benefit tradeoff: 
>the benefit 
>>>>>>>>> of knowing about a big move is worth the cost of frequent 
>>>>>>>>> notifications, but the benefit of knowing about small 
>moves is 
>>>>>>>>> less, and so isn't
>>>>>>> worth
>>>>>>>>> ambulance, etc. But when the workers finally arrive at the 
>>>>>>>>> coarse location, then you need a fine location to direct them 
>>>>>>>>> to the target.
>>>>>>> So
>>>>>>>>>>>>> a rate limit. If the target moves a little, 
>slowly, we get 
>>>>>>>>>>>>> slow
>>>>>>>>>>>> updates.
>>>>>>>>>>>>
>>>>>>>>>>>>>> WHY is it necessary to get a notification of 
>location even 
>>>>>>>>>>>>>> if
>>>>> the
>>>>>>>>>>>>>> Is this just a keep-alive? If so, why not 
>address the need 
>>>>>>>>>>>>>> for a keep-alive instead of imposing a requirement for 
>>>>>>>>>>>>>> location?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> target. This may be a reasonable way to do it, 
>but I have 
>>>>>>>>>>>>>>> two observations about the current throttle draft 
>>>>>>>>>>>>>>> relative to use
>>>>>>> with
>>>>>>>>>>>>>>> location.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> not sure if there are other uses for a maximum 
>time, but 
>>>>>>>>>>>>>>> we
>>>>> would
>>>>>>>>>>> need
>>>>>>>>>>>>>>> one for location.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Secondly, I observe that there are two ways to control 
>>>>>>>>>>>>>>> event notification. One way is expressed in the current 
>>>>>>>>>>>>>>> draft, which
>>>>>>> is
>>>>>>>>>>> a
>>>>>>>>>>>>>>> simple running average would be good enough, so 
>we would 
>>>>>>>>>>>>>>> not
>>>>> need
>>>>>>>>>>> to
>>>>>>>>>>>>>>> This list is for NEW development of the application of 
>>>>>>>>>>>>>>> SIP Use [email-masked] for 
>questions on 
>>>>>>>>>>>>>>> current
>>>>> sip
>>>>>>>>>>>>> Use [email-masked] for questions on 
>>>>>>>>>>>>> current sip Use [email-masked] for new developments of core 
>>>>>>>>>>>>> SIP
>>>>>>>>>>>>>
>>>>>>>>>> This list is for NEW development of the application 
>of SIP Use 
>>>>>>>>>> [email-masked] for questions on 
>current sip 
>>>>>> 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
>>>>>>
>>>>
>>>>
>>> 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
>>>
>> 
>> 
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 09 Aug 2008 00:42:07 -0400

Hi Krisztian,

> passed from the last notification.

Well, it still seems a bit odd to me. But I think the main thing thatSo, 
needs to be considered is to distinguish between voluntary filters 
applied by request of the caller, and authorization based filters that 
are applied because a subscriber isn't permitted to see certain parts of 
the state. In that case, notifications that show no change would leak 
information about state changes to inaccessible information.

If the filter is just related to the amount of change, not masking a 
particular piece of state, then this isn't a problem. But then this only 
applies to that class of filter.

So just to double check - if I am subscribed to presence with a filter 
that says to unconditionally exclude location - and I have a "min" 
throttle - will a change to the location trigger a notification based on 
the min throttle?

	Thanks,
	Paul

>>>>>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>> On
>>>>>>>>>>>>> Behalf
>>>>>>>>>>>>>>> Of Paul Kyzivat

---

From: "Song, Youngsun" <[email-masked]>
Date: Tue, 12 Aug 2008 11:52:13 -0400

Hello,

Could someone please describe the differences between RFC4722 and RFC5022 for MSCML? Is there anyplace that summarizes the changes?

Thanks for your help in advance.
YoungSun

---

From: "Diego A Alonso" <[email-masked]>
Date: Tue, 12 Aug 2008 13:03:41 -0300

Hi,
	4722 is Obsolete.
			
		Rgds,

				Diego

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Song, Youngsun
Sent: Tuesday, August 12, 2008 12:52 PM
To: [email-masked]'
Subject: [Sipping] Differences between RFC4722 and RFC5022 for MSCML

Hello,

Could someone please describe the differences between RFC4722 and RFC5022
for MSCML? Is there anyplace that summarizes the changes?

Thanks for your help in advance.
YoungSun
_______________________________________________
Sipping mailing list  https://www.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
No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.138 / Virus Database: 270.6.1/1605 - Release Date: 8/11/2008
4:59 PM

---

From: "Song, Youngsun" <[email-masked]>
Date: Tue, 12 Aug 2008 12:06:37 -0400

Hi Diego,

Could you please tell me why 4722 is obsoleted?

Thanks,
YoungSun

> From: Diego A Alonso [mailto:[email-masked]]
> Sent: Tuesday, August 12, 2008 12:04 PM
> To: Song, Youngsun; [email-masked]
> Subject: RE: [Sipping] Differences between RFC4722 and RFC5022 for MSCML
>
> Hi,
>         4722 is Obsolete.
>
>                 Rgds,
>
>                                 Diego
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Aug 2008 17:23:21 -0500

On 8/7/08 11:20 AM, Paul Kyzivat wrote:
>> every X seconds, no matter what will happen during the X seconds
>> with the *mix=Y* you are asking to receive an update, if something 
>> has changed, every Y second. So if you won't receive anything after Y 
>> second
> What you describe sounds like what would happen anyway - when there is 
> a change, you get notified.

The interesting thing here is what happens when <trigger> elements are 
used in filters associated with these subscriptions. The state may have 
changed, but it may not have changed enough to satisfy any of the 
<trigger> criteria.

That's the real value of setting a minimum amount of time between 
notifications.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Aug 2008 17:48:53 -0500

On 8/8/08 6:03 PM, [email-masked] wrote:
> complex but a simple running average.

And I promised to propose a coherent scheme that ties all three of these 
parameters together.

As Krisztian mentions, we'll have three "Event" header field parameters 
on the wire.

The first, "throttle", would work as described in the current draft.

The second, "force", would specify a maximum notification time period, 
in seconds. Whenever the time since the most recent notification exceeds 
the value in the "force" parameter, then the current state would be sent 
in its entirety (just like after a subscription refresh).

The third, "average", would specify an average cadence at which 
notifications are desired, in seconds. It works similar to the "force" 
parameter, except that it will slow down the speed at which 
notifications are sent if several have already been sent recently. I've 
played around with the numbers for this a bit, and I think I've found a 
formula that had good damping properties to satisfy this goal.

The formula has three inputs:

   1. "average" - The value of the "average" parameter conveyed in the
      "Event" header field, in seconds.

   2. "period" - The rolling average period, in seconds. We can discuss
      whether this is something we should be able to tune, or whether we
      can simply specify a reasonable period, such as 60 seconds.

   3. "count" - The number of notifications that have been sent during
      the last "period" seconds. When a subscription is initialized, we
      assume that notifications have been sent out at a cadence of one
      every "average" seconds. (i.e., count starts out as period/average)

The formula is:

  timeout = (average ^ 2) * count / period

The output of the formula, "timeout", is a timeout in seconds. Whenever 
the time since the most recent notification exceeds the value of this 
"timeout", then the current state would be sent in its entirety (just 
like after a subscription refresh). The timeout would be recalculated 
every "average" seconds. (I'm pretty certain that, in a properly 
functioning system, there is no way "timeout" can ever be less than 
"average").

Note that the "force" and "average" parameters make little sense to use 
together; however, there is no technical incompatibility between them.

/a

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 13 Aug 2008 08:34:49 +0100

No differences.  RFC 4722 was missing an important disclaimer as its an
Informational document and not standards track:

IESG Note

   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and in particular notes that the decision to publish is not
   based on IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.  Readers of
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Song, Youngsun
Sent: 12 August 2008 17:07
To: 'Diego A Alonso'; [email-masked]'
Subject: Re: [Sipping] Differences between RFC4722 and RFC5022 for MSCML

Hi Diego,

Thanks,
YoungSun

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Aug 2008 16:24:14 -0400

The change in location would not trigger a notification based on min.
However, if min was set, time would trigger a notification.  If you
unconditionally exclude location, the PIDF wouldn't contain location I would
think.

Brian

> Sent: Saturday, August 09, 2008 12:42 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Aug 2008 18:05:28 -0400

> unconditionally exclude location, the PIDF wouldn't contain location I would

Hmm. If I follow you, then indeed that would potentially leak 
information that the location, or at least something filtered out, has 
changed, even though it doesn't say how it has changed.

If this is just voluntary filters, and the changed information is 
potentially accessible, then this is no big deal.

But if this also applies to the sort of filtering that goes on due to 
lack of authorization to see a particular piece of information, then it 
*is* a problem. Just *knowing* that you have moved, when I am not 
authorized to see your location, could be a bad thing.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Aug 2008 17:13:40 -0500

> changed, even though it doesn't say how it has changed.

No. That's not what we're trying to say.

With this parameter (what Brian is calling "min" and I'm calling 
"force"), you'll get a notification. It doesn't matter whether something 
you can see has changed. It doesn't matter whether something you *can't* 
see has changed. It doesn't matter what triggers you have in place.

It will act *EXACTLY* *AND* *PRECISELY* *LIKE* the NOTIFY you get after 
a SUBSCRIBE refresh. If there's an information leak here, then it's been 
here for over 6 years.

But I don't think there is one.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Aug 2008 19:32:21 -0400

> But I don't think there is one.

OK, then I agree there is no information leak.

So in effect you are creating "session timer for subscriptions".

While I think it is unnecessary and wasteful to do this when there has 
been no change, I will not object - as long as it has been agreed that 
it is fine for a notifier to terminate the subscription when it knows 
that future notifications will all be redundant. In particular, when 
only location is being conveyed, and its for a UA with a fixed location. 
I think Brian agreed that made sense.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Aug 2008 10:10:48 -0500

On 8/13/08 6:32 PM, Paul Kyzivat wrote:
> only location is being conveyed, and its for a UA with a fixed 
> location. I think Brian agreed that made sense.

I think the plan is to make the parameters act pretty much like this 
kind of stuff does elsewhere -- that is, the client can send a requested 
"force" parameter of x, but the server can reply with an authoritatice 
"force: parameter of "y" (where y>= x). Presumably, this would include 
the case where y == infinity (i.e., removing the force parameter 
altogether).

Make sense?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Aug 2008 12:45:10 -0400

> the case where y == infinity (i.e., removing the force parameter 

Maybe its just me, but no, it doesn't make a lot of sense to me.

Thinking further about what this means - you say the notification you 
get is exactly line the initial notify after a subscription. That means 
the subscriber could achieve the same result by sending a reSUBSCRIBE at 
this minimum interval. The only value of this mechanism is then saving 
two messages - the SUBSCRIBE and its response. Is that worth it?

If so, then this is a lot like session timer. With that, there is only 
*one* interval to be negotiated. But there are potentially conflicting 
interests, with some wanting the value no smaller than X, and others 
wanting it to be no larger than Y. There is quite an elaborate set of 
machinery to negotiate this, involving two sip headers and a unique 
response code. I'm not certain there are analogous issues here, but it 
seems like there might be.

In any case, the rate value is a bit orthogonal to the question I was 
asking. The rate becomes moot if the subscription is terminated. I just 
want to ensure that it is acceptable behavior for the notifier to 
terminate the subscription when it believes it has said all there is to 
say on the subject, and that a subscriber that wants to be notified on 
an ongoing basis won't get upset with this.

In particular I am thinking of the gateways to millions (maybe billions) 
of landline phones that have fixed locations. When one of them makes a 
911 call, and that happens to be handled by a SIP PSAP, the GW ought not 
be required to maintain a subscription after having delivered the one 
and only address it has for that line.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Aug 2008 17:26:54 -0500

On 8/14/08 11:45 AM, Paul Kyzivat wrote:
> asking. The rate becomes moot if the subscription is terminated. I 
> just want to ensure that it is acceptable behavior for the notifier to 
> terminate the subscription when it believes it has said all there is 
> to say on the subject, and that a subscriber that wants to be notified 
> on an ongoing basis won't get upset with this.

Okay, I think I see what you're saying now. I agree that the question 
you're raising is unrelated to throttling. I would assert, then, that it 
does not need to be addressed in the throttle document.

I've changed the subject to reflect the (new, unrelated) topic you're 
raising.

> In particular I am thinking of the gateways to millions (maybe 
> billions) of landline phones that have fixed locations. When one of 
> them makes a 911 call, and that happens to be handled by a SIP PSAP, 
> the GW ought not be required to maintain a subscription after having 
> delivered the one and only address it has for that line. 

It seems to me that you'd want a new "reason" code to represent this 
kind of situation. I'll note it as an suggested improvement in the bug 
tracker for 3265.

/a

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 15 Aug 2008 11:11:38 +0200

Paul,

You may think that it is wasteful to notify when there are no changes
but there could be services which will monitor for 'no change'. These
types of services could monitor no change and perform actions if there
is no change after a specified period.

You do not want to rely on the absence of notifications to perform the
action as this could be a result of a failure in the system.

Having a minimum rate of notifications would be specified by the
specific service needing the data.

It is necessary to be able to specify that there is no minimum rate to
allow services which are only interested when changes do actually occur.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: 14 August 2008 00:32
To: Adam Roach
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06

Adam Roach wrote:
>>> unconditionally exclude location, the PIDF wouldn't contain location

>>> I would

	Thanks,
	Paul