[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:

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