[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
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 objectFrom sipping-bounces at ietf.org Thu Jul 31 08:18:01 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 D9FD83A6C8A;
Thu, 31 Jul 2008 08:18:01 -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 88FDC3A6C81
for <sipping at core3.amsl.com>; Thu, 31 Jul 2008 08:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120,
BAYES_00=-2.599]
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 1SqZyVTE7X0q for <sipping at core3.amsl.com>;
Thu, 31 Jul 2008 08:17:59 -0700 (PDT)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130])
by core3.amsl.com (Postfix) with ESMTP id 270173A6C6E
for <sipping at ietf.org>; Thu, 31 Jul 2008 08:17:59 -0700 (PDT)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp)
by ebru.winwebhosting.com with esmtpa (Exim 4.69)
(envelope-from <br at brianrosen.net>)
id 1KOZuC-0005ho-65; Thu, 31 Jul 2008 10:17:31 -0500
From: "Brian Rosen" <br at brianrosen.net>
To: "'Paul Kyzivat'" <pkyzivat at cisco.com>
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>
Date: Thu, 31 Jul 2008 11:17:22 -0400
Message-ID: <010e01c8f320$8c7881f0$12178182 at cis.neustar.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4891D3C7.8070000 at cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcjzHjJjqh9lK/JJTPmfeF5wM0/KkAAAHDbQ
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source:
X-Source-Args:
X-Source-Dir:
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-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces at ietf.org
Errors-To: sipping-bounces at ietf.org
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 m 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.
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: Rosenoving, 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.
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
, 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
> >>>>> 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