would make no normative change to rate control.
A fundamental thing that you would like to be able to control about location
is how fast you get updates. If an entity has a variable rate of speed, and
you set a motion filter, you also need to limit the rate. So "send me a
notification when the target moves by 30 meters, but don't send more than
one update per 10 seconds". So, there is an implied interaction between the
movement filter and the rate filter. However, I think the basic rate filter
does exactly what is needed. You will recall that the initial version of
this document had a rate control, but it was removed because of the rate
control draft.
There is a corresponding version of that "send me a notification when the
target moves by at least 30 meters, but send me a notification at least once
per 30 seconds even if it doesn't move by 30 meters". This is the point of
the "force" rate control mechanism.
The "30 seconds" is indeed seconds in most cases.
However, there is need to say "send me a notification within 10 seconds
meeting this quality specification" and that is what we are talking about.
That is NOT the initial notify upon subscription. It's the notify after
that.
In the emergency case, both the time and the quality are fixed, sometimes by
regulation, which is why we have the distinguished values in HELD. However,
this applies only to the first NOTIFY (after the subscription notify).
Thereafter, the normal rate control, and quality specifications should hold.
That's the mechanism we are discussing: how to get a different minimum
(force) value from the second and subsequent notifications.
So, summarizing:
a) Rate control is essential with location subscriptions
The rate control draft does what we want, except for the one case of being
able to specify the maximum time for the first notify after the subscription
(and the immediate NOTIFY that it triggers)
b) No change to rate control to get what we want is needed (modulo whatever
we do to solve the one case), and thus only an informative reference is
needed in this document
c) ResponseTime mixes time with quality. I'd prefer to have a explicit
quality filter, and use rate control to control the time aspect
d) The special case must be solved, possibly with some update to rate
control
Brian
> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:hannes.tschofenig@nsn.com]
> Sent: Saturday, August 08, 2009 10:53 AM
> To: ext Brian Rosen; Hannes Tschofenig; geopriv@ietf.org
> Subject: RE: [Geopriv] Making progress with the responseTime in loc-
> filters
>
> Hi Brian,
>
>
> >Okay, you want it on list. No problem.
>
> Maybe someone else has some good thoughts.
>
> >
> >We WILL use the rate control mechanism. However, this
> >interacts with ResponseTime.
>
> Well. In your previous mail you said that sipcore-event-rate-control is
> an informative reference. With this statement it does not seem to be
> that way.
>
> I don't even think that sipcore-event-rate-control makes sense for our
> application usage.
>
> Here are the use cases we wanted to cover (and those do not require the
> functionality from sipcore-event-rate-control):
>
> 1. the Target moves more than a specified distance since the last
> notification
>
> 2. the Target exceeds a specified speed
>
> 3. the Target enters or exits a region (described by a circle or a
> polygon)
>
> 4. one or more of the values of the specified address labels have
> changed for the location of the Target. For example, the value
> of the <A1> civic address element has changed from 'California'
> to 'Nevada'.
>
> 5. the type of location information being requested.
>
>
> We limit the number of notifications by utilizing location semantic not
> via min/max/avg indication.
>
> >ResponseTime, in HELD is a quality request: it's a hint to the
> >server of what kind of mechanisms the server may use, and how
> >it should use them, in order to achieve the desired response
> >time.
>
> I agree.
>
> The "symbolic label" (namely responseTime="emergencyRouting" or
> responseTime="emergencyDispatch") probably cover most of the cases we
> care about.
>
>
> >The normal use really is seconds, and I would not wish
> >to see this restricted to just the defined special values for
> >emergencies.
>
> Might be interesting to know what application developers like to use
> more.
>
> >
> >The rate control mechanism has what we basically need:
> >min/max/average notification rate.
>
> Not at all. From the previous discussion this does not really follow.
>
> >
> >However, there is a problem, specific to location, which
> >derives from the problem that the FIRST response often takes
> >longer that subsequent responses.
>
> The first response to the SUBSCRIBE comes immediately (and it might be
> empty).
>
> >That means the "minimum"
> >thing is "ResponseTime" for the first, but not subsequent
> >notifications. To put it another way, we need a way to
> >specify the (minimum) time to get the first response, and then
> >the minimum time before the next notification must be sent.
> >That can't be done with rate control as is.
>
> I agree with you when someone wants to use sipcore-event-rate-control
> in
> combination with the loc-filters document. This only makes sense when
> the functionality in loc-filters is largely not used (expect for the
> responseTime parameter). Why would someone use, for example, the the
> Target enters or exits a region functionality in combination with a
> min/max/avg rate limiting mechanism?
>
> My current thinking is that we are adding functionality that makes the
> entire implementation more complex without a lot of added value.
>
>
> >
> >So, either we need to enhance the rate control mechanism to
> >let us specify first and subsequent "force" (minimum) values,
> >or we use responseTime to specify the first notify time and
> >rate control for subsequent ones. The latter, to me is
> >"yuck". The former requires the authors (and work group) for
> >rate control to agree.
>
> I prefer the first (requiring changes only to
> sipcore-event-rate-control) and particuarly not demand that anyone uses
> sipcore-event-rate-control with loc-filters other than an optional
> feature.
>
> >
> >But "responseTime" is really a proxy for a request for a
> >particular quality.
> >It's "give me the best quality location I can get in this much
> >time". We really would like a filter on quality, with the
> >caveat that we have to deal with an overspecified set of
> >filters that the server can't meet.
>
> For me, there is also the question about how the responseTime parameter
> (in HELD and also in this loc-filters document) align with
> http://tools.ietf.org/id/draft-thomson-geopriv-location-quality-04.txt
> (which is yet another optional extension).
>
>
> Ciao
> Hannes
>
> >
> >Brian
> >
> >
> >
> >> -----Original Message-----
> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >> Sent: Friday, August 07, 2009 2:53 PM
> >> To: 'Brian Rosen'; Tschofenig, Hannes (NSN - FI/Espoo);
> >> geopriv@ietf.org
> >> Subject: RE: [Geopriv] Making progress with the responseTime in loc-
> >> filters
> >>
> >> >On the rate control reference, while I would like to see the
> >> >reference to call attention, it could be informative, and isn't
> >> >required; one can use the rate control to achieve the purpose you
> >> >describe, and no further mechanism is required.
> >>
> >> Informative references sound nice but then you have options that
> >> someone could implement and someone has to check whether
> >there is some
> >> undesired interaction with other functionality, such as with
> >> responseTime.
> >>
> >> >
> >> >On ResponseTime, more work is needed, and I think we need an author
> >> >proposal to chew over.
> >>
> >> I don't see what additional work is need other than
> >describing what I
> >> listed below and to move the attribute into an element.
> >>
> >> >
> >> >Working on it.
> >> >
> >> >Brian
> >> >
> >> >> -----Original Message-----
> >> >> From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On
> >> >> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> >> >> Sent: Friday, August 07, 2009 1:02 PM
> >> >> To: geopriv@ietf.org
> >> >> Subject: [Geopriv] Making progress with the responseTime in
> >> >> loc-filters
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I would like to conclude the responseTime discussion and
> >> >close an open
> >> >> issue with the current document. For this purpose, I need your
> >> >> feedback.
> >> >>
> >> >> Here are the issues I can see:
> >> >>
> >> >> 1) REFERENCE TO SIPCORE-EVENT-RATE-CONTROL
> >> >>
> >> >> Based on the suggestion by Martin some time back I removed any
> >> >> reference to sipcore-event-rate-control.
> >> >>
> >> >> sipcore-event-rate-control is only be needed if we want
> >> >functionality
> >> >> like
> >> >>
> >> >> -- "Send me location updates with a minimum time
> >> >> period between two notifications".
> >> >>
> >> >> -- "Send me location updates with a maximum time period
> >> >> between two notifications."
> >> >>
> >> >> Currently, we make the notifications dependent on the degree of
> >> >> location change.
> >> >>
> >> >> Do we really need the functionality defined in
> >> >>
> >http://tools.ietf.org/html/draft-ietf-sipcore-event-rate-control-00
> >> >> for this document?
> >> >>
> >> >>
> >> >> 2) RESPONSETIME ATTRIBUTE
> >> >>
> >> >> This has triggered some discussion and my current
> >> >understanding (and I
> >> >> was not at the IETF meeting and hence did not participate in the
> >> >> hall-way conversations etc. etc.) is the following:
> >> >>
> >> >> Martin does not like 'responseTime' to be an XML attribute of the
> >> >> <locationType> element. Fine. Not a big issue.
> >> >>
> >> >> How are notifications sent when someone sets
> >> >> responseTime="emergencyRouting" or
> >responseTime="emergencyDispatch"
> >> >> but the LIS is unable to provide the requested location
> >immediately
> >> >> (which is quite likely in many environments)?
> >> >>
> >> >> Here is a figure:
> >> >>
> >> >> Location
> >> >> Recipient LIS
> >> >> |-----SUBSCRIBE---->| Request state subscription
> >> >> |<-------200--------| Acknowledge subscription
> >> >> |<------NOTIFY-(1)- | Return current state information
> >> >> |--------200------->|
> >> >> |<------NOTIFY-(2)- | Return current state information
> >> >> |--------200------->|
> >> >>
> >> >>
> >> >> My reading of RFC 3265 is that a SIP NOTIFY (1) is sent
> >> >immediately in
> >> >> response to the initial SUBSCRIBE and may contain an empty body.
> >> >>
> >> >> Then, when location is available (as desired) another
> >NOTIFY (2) is
> >> >> sent. This then contains the desired answer.
> >> >>
> >> >> Why aren't we happy with this behavior?
> >> >>
> >> >> We could obviously make this behavior more explict in the
> >document.
> >> >>
> >> >> 3) NUMERICAL VALUES IN RESPONSETIME
> >> >>
> >> >> The labels "emergencyRouting" and "emergencyDispatch" make a lot
> >> >> of sense for our purpose. When it comes to the numerical values
> >> >I am less
> >> >> clear whether we need them in the loc-filters document.
> >Here is the
> >> >> text from the HELD document (Section 6.1 of
> >> >> http://www.ietf.org/id/draft-ietf-geopriv-http-location-delivery-
> >> >> 15.txt)
> >> >> :
> >> >>
> >> >> The "responseTime" attribute includes a time value
> >> >> indicating to the LIS how long the Device is prepared to
> >> >wait for a
> >> >> response or a purpose for which the Device needs the location.
> >> >>
> >> >> So, do we need this functionality?
> >> >>
> >> >> Ciao
> >> >> Hannes
> >> >> _______________________________________________
> >> >> Geopriv mailing list
> >> >> Geopriv@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/geopriv
> >> >
> >> >_______________________________________________
> >> >Geopriv mailing list
> >> >Geopriv@ietf.org
> >> >https://www.ietf.org/mailman/listinfo/geopriv
> >> >
> >
> >
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
