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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Jul 2008 08:15:54 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Jul 2008 09:32:11 -0400

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 29 Jul 2008 09:40:59 -0400

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.

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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Jul 2008 10:04:26 -0400

> 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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Jul 2008 11:42:16 -0400

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

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2008 10:04 AM
> To: Brian Rosen
> Cc: Rosen, Brian; 'sipping'
> > 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
> >> Subject: Re: [Sipping] Comments on
draft-niemi-sipping-event-throttle-
> 06
> >>> limit, the latter is a longer term average.  For this purpose, I
think
> a
> >>> keep much history state.  I think most applications are better
served
> by
> >>> Sipping mailing list
https://www.ietf.org/mailman/listinfo/sipping

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Jul 2008 13:38:46 -0400

> So, maybe we need a series of filters.  A min rate is so much simpler

Now that I think about it, those devices that don't move may not be very 
happy about maintaining a presence subscription for their unchanging 
location, if that is the only sort of presence they support.

Perhaps in that case the server will simply send an initial notification 
with the location and simultaneously terminate the subscription. 
(Holding the subscription is all cost and no benefit.) Will a subscriber 
be happy with that? Or will it keep polling?

	Thanks,
	Paul

> draft-niemi-sipping-event-throttle-06
>>
>>
>> Brian Rosen wrote:

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 30 Jul 2008 08:25:06 -0400

Generally, a watcher would really like to know that location will never
change.  It would be good to get a definitive "this is all you are going to
get" indication.

Brian

> Sent: Tuesday, July 29, 2008 1:39 PM
> To: Rosen, Brian
> Cc: Brian Rosen; sipping

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 30 Jul 2008 08:28:13 -0400

Ah, one detail.  "Send an initial notification" may not be the one that
occurs immediately after receiving the subscription, as location
determination could take some time, even for situations where the target is
known to not move.  However, you may get one notification with location, and
then get the subscription terminated.  That could work.

Brian

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 30 Jul 2008 16:26:07 +0300

Hi Brian,

that is a good point,
NOTIFY with location information immediately after 200 OK without any 
*pending state*, as someone has proposed at least
in the draft-winterbottom-sip-location-package-00 for location 
information doesn't work.
The problem is long time to retrieve/determine location in some cases 
and secondly, rule on authorization of location request
may include that target user is asked about reveling own location 
information.
So here my question:
do you see any problem to receive a *pending state* and then receive the 
NOTIFY with location,
and finally get the subscription terminated?

Sal

Brian Rosen wrote:
>>>>> a rate limit.  If the target moves a little, slowly, we get slow
>>>>>           
>>>> updates.
>>>>
>>>> this discussion that you were requesting unconditional notifications
>>>>         
>>> of
>>>       
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>             
>>>> Behalf
>>>>         
>>>>>> Of Paul Kyzivat
>>>>>>> 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
>>>       
>>>>>>> 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
>>>>         
>>>>>>> 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.
>>>>>>>
>>>>>>> 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
>>>       
>>>>>>> simple running average would be good enough, so we would not need
>>>>>>>               
>>> to
>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 30 Jul 2008 12:26:15 -0400

I am somewhat conflicted.  On the one hand, I am a believer in being
specific, and thus, in general, I'd prefer the initial return from the
subscribe indicate in someway that there is the possibility of further
location information (i.e. if the location returned in the immediate NOTIFY
is all there is going to be).  I suppose we could infer that from an
immediate termination of the subscription.

We then may get one more NOTIFY.  I suppose we could infer that from
termination of the subscription at that point.  If we don't then we may get
updates of location for the duration of the subscription at that point.

I'd rather have something in the responses from the presence server of that
information rather than inferring it from subscription termination.

Brian

> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2008 9:26 AM
> To: Brian Rosen
> Cc: 'Paul Kyzivat'; Rosen, Brian; 'sipping'

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jul 2008 12:44:58 -0400

The subscription can be terminated by the notifier on any NOTIFY.
But in general it is a stretch to infer from that that the location will 
no longer change. At best that would be a convention among a community 
of users. For it to be more explicit, I think something needs to be 
included in the data to say it.

It is more reasonable to simply draw the conclusion "I'm not getting any 
more information from this source" than "the presentity is known to be 
fixed in space". For all practical purposes they may serve the same 
purpose.

If a notifier has terminated the subscription, in which cases does it 
make sense to attempt to reestablish it, and when not? Perhaps there 
should be a Retry-After header in the terminating NOTIFY. But that 
doesn't say quite the right thing either.

	Paul

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 30 Jul 2008 15:03:23 -0400

Could "retention-expires" element help here? The default value is 24
hours, so there should not be any issue with watcher subscribing again
after this timer is about to expire.
Else probably another xml element can be added, which indicates that
location info is static and when watcher gets it in a terminating
Notify, it can infer that the subscription was terminated since there
won't be any more location updates. When the watcher logs in again, it
will subscribe again.

Sanjay

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
>Sent: Wednesday, July 30, 2008 12:45 PM
>To: Brian Rosen
>But in general it is a stretch to infer from that that the 
>location will no longer change. At best that would be a 
>convention among a community of users. For it to be more 
>explicit, I think something needs to be included in the data to say it.
>
>It is more reasonable to simply draw the conclusion "I'm not 
>getting any more information from this source" than "the 
>presentity is known to be fixed in space". For all practical 
>purposes they may serve the same purpose.
>
>If a notifier has terminated the subscription, in which cases 
>does it make sense to attempt to reestablish it, and when not? 
>Perhaps there should be a Retry-After header in the 
>terminating NOTIFY. But that doesn't say quite the right thing either.
>
>	Paul
>
>Brian Rosen wrote:
>> location information (i.e. if the location returned in the immediate 
>> NOTIFY is all there is going to be).  I suppose we could infer that 
>> from an immediate termination of the subscription.
>> 
>> termination of the subscription at that point.  If we don't then we 
>> may get updates of location for the duration of the 
>subscription at that point.
>> 
>> I'd rather have something in the responses from the presence 
>server of 
>> that information rather than inferring it from subscription 
>termination.
>> 
>> Brian
>> 
>>> *pending state*, as someone has proposed at least in the 
>>> draft-winterbottom-sip-location-package-00 for location information 
>>> doesn't work.
>>> and secondly, rule on authorization of location request may include 
>>> that target user is asked about reveling own location information.
>>> So here my question:
>>> do you see any problem to receive a *pending state* and 
>then receive 
>>> the NOTIFY with location, and finally get the subscription 
>>> terminated?
>>>
>>> Sal
>>>
>>>
>>>
>>> Brian Rosen wrote:
>>>> Ah, one detail.  "Send an initial notification" may not be the one 
>>>> that occurs immediately after receiving the subscription, as 
>>>> location determination could take some time, even for situations 
>>>> where the target
>>> is
>>>> known to not move.  However, you may get one notification with 
>>>> location,
>>> and
>>>>>> So, maybe we need a series of filters.  A min rate is so much 
>>>>>> simpler than that :)
>>>>>>
>>>>> Now that I think about it, those devices that don't move 
>may not be
>>> very
>>>>> happy about maintaining a presence subscription for their 
>>>>> unchanging location, if that is the only sort of presence 
>they support.
>>>>>
>>>>>>> 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
>>>>>>
>>>>>>> Its significant for the large population of devices that have a 
>>>>>>> fixed location.
>>>>>>>
>>>>>>> 	Paul
>>>>>>>
>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>>> It was suggested in geopriv that -throttle be used 
>to control 
>>>>>>>>>> the
>>>>>>>>>>
>>>>>> rate
>>>>>>
>>>>>>>>>> observations about the current throttle draft 
>relative to use 
>>>>>>>>>> with location.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>
>>>>>>>>>> limit, the latter is a longer term average.  For 
>this purpose, 
>>>>>>>>>> I
>>>>>>>>>>
>>>>>> think
>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>>>> 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 
>>>>>>>> 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: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Jul 2008 09:22:20 -0400

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.

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

> 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.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2008 11:01:27 -0400

> seconds, and another with a min move of 1 cm and a throttle of 60 seconds.

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Jul 2008 11:17:22 -0400

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.

Brian

> Sent: Thursday, July 31, 2008 11:01 AM
> To: Brian Rosen

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2008 12:36:13 -0400

> 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

---

From: Cary FitzGerald <[email-masked]>
Date: Thu, 31 Jul 2008 10:17:57 -0700

I would imagine that most of the time when there are big moves, they  
are at a constant velocity and in the same direction and therefore not  
terribly interesting.  What would be interesting is changes in the  
second derivatives.

Cary.

On Jul 31, 2008, at 9:36 AM, Paul Kyzivat wrote:

>> a while, you want to update the location.  If you set the update  
>> rate to be the same, but a very small motion change
> 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.
>
>>>> 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
>>>> You need one subscription with a min move of 10 meters and a  
>>>> throttle of
>>> 6
>>>> So, I'm back to needing min, recognizing that it's not a direct  
>>>> answer
>>> to
>>>> Several of us had a meeting today at IETF where this was  
>>>> discussed, and
>>> a
>>>>> Subject: RE: [Sipping] Comments on draft-niemi-sipping-event- 
>>>>> throttle-
>>> 06
>>>>> Ah, I get it.
>>>>>
>>>>> simpler
>>>>>> ability to
>>>>>> from
>>>>>> fixed
>>>>>>>>> This

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2008 14:44:17 -0400

Cary FitzGerald wrote:
> I would imagine that most of the time when there are big moves, they are 
> at a constant velocity and in the same direction and therefore not 

I don't know about that. They are probably from a vehicle, following a 
road. Just getting the values and plotting them on a map is probably a 
lot more useful for predicting future location or how to intercept.

The smaller variations may be somebody walking around in a house or 
office, etc.

	Paul

>>> a while, you want to update the location.  If you set the update rate 
>>> to be the same, but a very small motion change
>>> 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
>> 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 
>>>>> Several of us had a meeting today at IETF where this was discussed, 
>>>>> and
>>>> a
>>>>>> Subject: RE: [Sipping] Comments on 
>>>>>>>>> [mailto:[email-masked]] On
>>>>>>> Behalf
>>>>>>>>> Of Paul Kyzivat

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Jul 2008 19:53:06 -0400

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.

Which is simpler?

Brian

> Sent: Thursday, July 31, 2008 12:36 PM
> To: Brian Rosen
> Cc: 'sipping'
> >>> You need one subscription with a min move of 10 meters and a throttle
> of
> >> 6

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2008 22:21:33 -0400

> 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