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

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

It works, it's just too much signaling.  It's also hard for the watcher to
know when to switch.

I really think min is s simpler mechanism.

I've been talking to the throttle authors.  I'll have a proposal on the list
shortly.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Thursday, July 31, 2008 10:22 PM
> To: Brian Rosen
> Cc: 'sipping'
> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
> 
> 
> 
> Brian Rosen wrote:
> > 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.
> 
> 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
> 
> 
> > 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
> >

_______________________________________________
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