[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
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
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> 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:pkyzivat at cisco.com]
> >> 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: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
> >>>
> >
> >
_______________________________________________
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