Subject: [Geopriv] Making progress with the responseTime in loc-filters

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 7 Aug 2009 20:02:21 +0300

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Aug 2009 14:29:36 -0400

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.

On ResponseTime, more work is needed, and I think we need an author proposal
to chew over.

Working on it.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Friday, August 07, 2009 1:02 PM
> To: [email-masked]
> Subject: [Geopriv] Making progress with the responseTime in loc-filters
> 
> Hi all,
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 7 Aug 2009 21:53:00 +0300

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

>> Based on the suggestion by Martin some time back I removed any 
>> reference to sipcore-event-rate-control.
>> 
>> Currently, we make the notifications dependent on the degree of 
>> location change.
>> 
>> http://tools.ietf.org/html/draft-ietf-sipcore-event-rate-control-00 
>> for this document?
>> 
>> 
>> 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
>> clear whether we need them in the loc-filters document. Here is the 
>> text from the HELD document (Section 6.1 of

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Aug 2009 15:43:24 -0400

Okay, you want it on list.  No problem.

We WILL use the rate control mechanism.  However, this interacts with
ResponseTime.

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.  The normal use really is
seconds, and I would not wish to see this restricted to just the defined
special values for emergencies.

The rate control mechanism has what we basically need: min/max/average
notification rate.

However, there is a problem, specific to location, which derives from the
problem that the FIRST response often takes longer that subsequent
responses.  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.

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.

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.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, August 07, 2009 2:53 PM
> To: 'Brian Rosen'; Tschofenig, Hannes (NSN - FI/Espoo);
> [email-masked]
> Subject: RE: [Geopriv] Making progress with the responseTime in loc-
> filters
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 8 Aug 2009 17:53:24 +0300

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. 

>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

>> >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
>> >
>> >> The labels "emergencyRouting"  and "emergencyDispatch" make a lot 
>> >> of sense for our purpose. When it comes to the numerical values
>> >I am less

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 9 Aug 2009 19:15:52 -0500

Hi Hannes,

1) The functions provided by event-rate-control are useful in the context of location.  However, that doesn't say anything about whether loc-filters needs to include a reference, directly or otherwise.

My current opinion is that loc-filters should avoid dealing with these issues.  That means responseTime remains out of scope.

~~
2) responseTime is intrinsically linked to event rate control.  As Brian pointed out, this is about that first _complete_ NOTIFY (what you refer to as the second NOTIFY).  Min-interval throttles this, perhaps unnecessarily.

We discussed this on and off with Adam Roach.  Adam suggested that we could use max-interval to force this NOTIFY.  On face value, that works quite well, but it smells off to me.

 a) The min-interval throttling interacts with this and max-interval must be greater than min-interval.  Therefore, a low value of min-interval must also be specified for the first NOTIFY.

 b) After first notification the "special" behaviour must be reverted; here, Adam suggested using the 200 response to the NOTIFY to convey updated values*.

 c) The notifier/PA might not be willing to support appropriately low values of max-interval.  I think that this is the showstopper.  (Note that it can't assume that the watcher is going to update intervals after the first NOTIFY.)

 d) The quality semantic provided by responseTime is lost.  I don't care so much about this as much because a subscription provides the means to avoid the need to this parameter, but it's still nice to have.  One advantage of having an explicit tag is that it carries a strong semantic: "responseTime" means "only take this long to generate (location) information", which still has some value in a subscription.

* There's an issue here where the watcher doesn't get informed of the final values until the next NOTIFY, but we agreed that's minor enough to worry about.

~~
3) I get the impression that we're looking at different use cases when you make this suggestion.  I almost made an entirely opposite suggestion.  Values in seconds are still very useful...outside of emergency use cases, of course.

~~
I'm thinking that a concrete proposal is needed.  I might write one up.

--Martin

> Sent: Saturday, 8 August 2009 3:02 AM
> To: [email-masked]
> location

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Aug 2009 10:44:33 -0400

Reference to rate control is informative because, I think, this document
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

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: Saturday, August 08, 2009 10:53 AM
> To: ext Brian Rosen; Hannes Tschofenig; [email-masked]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 10 Aug 2009 18:48:12 +0300

The following statement from Brian explains the disconnect between
Martin/Brian and myself: 

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

We clearly had different requirements in mind. For me the requirement was
just to provide the "send me a notification when the target moves by 30
meters" functionality. 

I let someone else decide about this aspect (but at least I now understand
the intention)[*]. 

Ciao
Hannes

PS: [*] It is unfortunate that I wasn't at the IETF meeting because I would
have very likely recognized the disconnect between Brian/Martin's view and
mine much earlier.

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 11 Aug 2009 09:32:51 -0600

All -

I have forwarded this discussion thread to OGC members who 1.) deal with 
location services applications and 2.) deal with alerting applications 
driven by sensor networks.

Cheers

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "'Brian Rosen'" <[email-masked]>; "Tschofenig, Hannes (NSN - 
FI/Espoo)" <[email-masked]>; <[email-masked]>
Sent: Monday, August 10, 2009 9:48 AM
Subject: [Geopriv] Clarification regarding Loc-Filters

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 12 Aug 2009 12:01:17 -0600

The OGC Members (especially in Europe) have been developing and testing a 
candidate OGC standard titled "Event Pattern Markup Language (EML - OGC 
08-132). The Event Pattern Markup Language (EML) allows one to describe 
event patterns for event (stream) processing and analysis. It can be used to 
build multi stage filters for incoming events but also to derive higher 
information through combining and correlating multiple events. It can be 
applied on single events but is focused on handling of continuous event 
streams. http://portal.opengeospatial.org/files/?artifact_id=29566

This work is being driven by numerous projects in Europe related to INSPIRE, 
SANY, and ORCHESTRA, pan-European projects that deal with spatial data 
infrastructures integrated with sensor networks (such as landslide 
monitoring) and risk management/emergency services.

Attached is an example of a EML encoding related to the GeoPriv loc filter 
discussions.

Perhaps not as "simple" and "concise" as this group is envisioning but this 
is also not necessarily a simple problem when considering a more general 
solution.

Hope this helps

Carl

----- Original Message ----- 
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: "ext Carl Reed" <[email-masked]>
Sent: Wednesday, August 12, 2009 1:20 AM
Subject: RE: [Geopriv] Clarification regarding Loc-Filters

> Thanks, Carl.
>
> I am interested to hear what their thinking is
>
>>From: ext Carl Reed [mailto:[email-masked]]
>>Sent: 11 August, 2009 18:33
>>To: Hannes Tschofenig; 'Brian Rosen'; Tschofenig, Hannes (NSN
>>- FI/Espoo); [email-masked]
>>Subject: Re: [Geopriv] Clarification regarding Loc-Filters
>>
>>All -
>>
>>I have forwarded this discussion thread to OGC members who 1.)
>>deal with location services applications and 2.) deal with
>>alerting applications driven by sensor networks.
>>
>>Cheers
>>
>>Carl
>>
>>To: "'Brian Rosen'" <[email-masked]>; "Tschofenig, Hannes
>>(NSN - FI/Espoo)" <[email-masked]>; <[email-masked]>
>>>>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.
>>>
>>> We clearly had different requirements in mind. For me the
>>requirement
>>> was just to provide the "send me a notification when the
>>target moves
>>> by 30 meters" functionality.
>>>
>>> I let someone else decide about this aspect (but at least I now
>>> understand the intention)[*].
>>>
>>> Ciao
>>> Hannes
>>>
>>> PS: [*] It is unfortunate that I wasn't at the IETF meeting
>>because I
>>> would have very likely recognized the disconnect between
>>> Brian/Martin's view and mine much earlier.
>>>