[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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