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

[Paul Kyzivat <pkyzivat at cisco.com>]

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: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions on current sip
>>> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
>> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP


in; charset="us-ascii"; Format="flowed"
Sender: sipping-bounces at ietf.org
Errors-To: sipping-bounces at ietf.org



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: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions on current sip
>>> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
>> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP