[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:
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 toFrom sipping-bounces at ietf.org Thu Jul 31 19:21:04 2008
Return-Path: <sipping-bounces at ietf.org>
X-Original-To: sipping-archive at optimus.ietf.org
Delivered-To: ietfarch-sipping-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 72D0E3A6C34;
Thu, 31 Jul 2008 19:21:04 -0700 (PDT)
X-Original-To: sipping at core3.amsl.com
Delivered-To: sipping at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F0F213A6BF7
for <sipping at core3.amsl.com>; Thu, 31 Jul 2008 19:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id JKtpmKQhAfm3 for <sipping at core3.amsl.com>;
Thu, 31 Jul 2008 19:21:01 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70])
by core3.amsl.com (Postfix) with ESMTP id 397963A6C34
for <sipping at ietf.org>; Thu, 31 Jul 2008 19:21:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,289,1215388800"; d="scan'208";a="60233407"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
by sj-iport-1.cisco.com with ESMTP; 01 Aug 2008 02:21:00 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m712L0RG014509;
Thu, 31 Jul 2008 19:21:00 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
[64.102.31.102])
by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m712KxEi010383;
Fri, 1 Aug 2008 02:21:00 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 31 Jul 2008 22:20:59 -0400
Received: from [10.86.249.3] ([10.86.249.3]) by xfe-rtp-201.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 31 Jul 2008 22:20:59 -0400
Message-ID: <4892732D.8040602 at cisco.com>
Date: Thu, 31 Jul 2008 22:21:33 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Brian Rosen <br at brianrosen.net>
References: <C80ADC57CB3BB64B94A9954A816306C549A5BC at STNTEXCH11.cis.neustar.com> <488F1BDB.2000607 at cisco.com> <010201c8f180$c21a71c0$12178182 at cis.neustar.com> <488F236A.1000501 at cisco.com> <C80ADC57CB3BB64B94A9954A816306C549A60C at STNTEXCH11.cis.neustar.com> <00b101c8f310$7aa4b4e0$12178182 at cis.neustar.com> <4891D3C7.8070000 at cisco.com> <010e01c8f320$8c7881f0$12178182 at cis.neustar.com> <4891E9FD.3060605 at cisco.com>
<009601c8f368$96371600$12178182 at cis.neustar.com>
In-Reply-To: <009601c8f368$96371600$12178182 at cis.neustar.com>
X-OriginalArrivalTime: 01 Aug 2008 02:20:59.0239 (UTC)
FILETIME=[3C8CEF70:01C8F37D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10576; t=1217557260;
x=1218421260; c=relaxed/simple; s=sjdkim4002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=pkyzivat at cisco.com;
z=From:=20Paul=20Kyzivat=20<pkyzivat at cisco.com>
|Subject:=20Re=3A=20[Sipping]=20Comments=20on=20draft-niemi
-sipping-event-throttle-06 |Sender:=20;
bh=Ah6pAjiHcYSt1VlOVML1nsb8RcLHHKD0jn0WhIUy+ko=;
b=FEltPLFgOfYpsJeWvnTRYpUpRDHqQYMU73OLKEgDzIEG14OR3Up/6jmA8d
epYkB8A1IOqdijk75XTkG+B5SIkH/6d7JFVtCtlg430Rb5rzlHMkGTDC7eCs
KQtFBvOxUU;
Authentication-Results: sj-dkim-4; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/sjdkim4002 verified; );
Cc: 'sipping' <sipping at ietf.org>
Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
X-BeenThere: sipping at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping at ietf.org>
List-Help: <mailto:sipping-r 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
equest at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sipping-bounces at ietf.org
Errors-To: sipping-bounces at ietf.org
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 tone 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
hem, 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