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

["Rosen, Brian" <Brian.Rosen at neustar.biz>]

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:pkyzivat at cisco.com]
> 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: 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