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