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

["Brian Rosen" <br at brianrosen.net>]

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

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen at neustar.biz]
> 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: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