Subject: RE: [Geopriv] HELD comment on responseTime parameter

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 03:37:17 -0500

I'm hoping that the silence might mean that people are feeling more
sympathetic to supporting this parameter - with the agreed default
semantics.

Am I overly optimistic?

Cheers,
Martin

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, 1 August 2007 9:12 AM
To: Rohan Mahy
Cc: [email-masked]; Mary Barnes
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Hi Rohan,

Per the key question:

     How does the client and/or application know that it is OK to wait 5
     seconds?  Can you describe an example use case (a vignette) with a
     sample time?

I think the only entity that can possibly know how long it is OK to wait
is the client/application. The location server certainly doesn't know
what the context of the application is. All I'm asking is that the
client be able to inform the server of this so the server can optimize
the result for the client.

Some vinaigrettes :) :

1. A "local services" application running on a PDA is asked to provide
the nearest teller machines to the current location. It can provide
visual feedback to the user that it is determining their current
location. It thinks that a minute is a reasonable amount of time to ask
the user to wait in this context. The application sends the location
request to the LIS telling it that it is prepared to wait up to a minute
for the response. The LIS provides the optimal location value - which
may take considerably less than a minute.

2. A location-based interactive gamer wants an updated list of all
fellow
team members in the current geographical vicinity. It's a tactical
message. The application thinks this needs to be accomplished within ten
seconds. It requests the game server to get all team members to update
their location. All team member application instances request a location
update with a five second response time. If no location is retrieved,
the application returns the last known location, suitably tagged as
such, for display at the requesting player's terminal.

3. A VoIP call is being placed that is subject to location based
routing. The call is urgent. The VoIP application requests the current
location from the LIS and tells it that it needs a location in 2 seconds
for incorporation in the SIP invite.

4. A pizza delivery application (having been accurately routed to) wants
a more accurate location for pizza delivery. The pizza dispatcher asks
the caller for their current accurate location. The caller consults the
auto-location determiner application on their PDA and tells it to see
what it can work out in the next 30 seconds. The LIS applies optimal
location determination technology given that time frame.

Now, to turn things around, I'd actually like an example of a
client/application that wouldn't apply some sort of timeout to the
request that it sends to a LIS. All I'm asking is that this particular
piece of information be passed on to the LIS to facilitate the location
determination process. We'd already agreed on some reasonable default
semantics where an application doesn't provide this guidance. The
fundamentals of the objection escape me.

Cheers,
Martin

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Wednesday, 1 August 2007 7:21 AM
To: Dawson, Martin
Cc: Brian Rosen; Stark, Barbara; Mary Barnes; [email-masked]
Subject: Re: [Geopriv] HELD comment on responseTime parameter

Hi,

One important question inline...

On 7/21/07, Dawson, Martin <[email-masked]> wrote:
> Hi Brian,
>
> I think the fact that you feel the need to quantify "right away" and
> "I'll wait" is revealing in itself. Of course "right away" literally
> means zero wait and "I'll wait" is any time up to infinity. The values
> you "prescribe" are based on your here/now understanding and
presumption
> of specific applications.
>
> Requesting location in a WCDMA UTRAN can involve relating the serving
> cell directly to a nominal area of coverage (msec), putting the device
> into soft handoff to collect a set of round-trip time measurements
from
> in-range base stations (a few seconds), or doing A-GPS (up to, say, 30
> seconds). Each places different demands on network resources.
>
> The cell-based location may be adequate for accurate PSAP routing 67%
> while RTT may be accurate 99.9% of time. Other applications will
> similarly be sensitive to accuracy variations. Tolerance for response
> delays isn't something you can claim to be able to predict for all
> applications today and forever.
>
> It's no good saying that an application that asked for a four second
> response might say "oh - if I'd known I could have had the result in
> five seconds, I'd have been OK to wait."

> If it is OK to wait five seconds, then it should request a response
time of at least five
> seconds.

How does the client and/or application know that it is OK to wait 5
seconds?  Can you describe an example use case (a vignette) with a
sample time?

In the medical world, labs are often asked to provide results in
roughly these time scales:
STAT:  immediately.  drop everything.
ASAP: As Soon As Possible.  Do it now unless you are doing something
STAT
Next Available: when you would normally get it done.
Double Check: Be extra thorough and rigorous. Take as long as you need.

I am wondering if this is more along the lines of what the client
wants to specify.

thanks,
-rohan
> As we've explained before, our experience has shown that the Low-delay
> or Delay-tolerant choices that the 3GPP protocols provide have been
> problematic. At least in that case there has been an accompanying
> (scalar) accuracy requirement to go along with the QoS. The latter has
> at least facilitated some ability to arbitrate between location
> techniques and order of fallback. With just a binary response time
> requirement, it would be impossible to do any arbitration.
>
> If you assume you know everything now and force a binary choice into
the
> semantics, then you can't undo that if it's a mistake. If the
semantics
> support a scalar response time and it turns out that 100msec and 30sec
> is all anyone ever needs then, at worst, that is what ends up being
put
> in all the HELD requests.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Saturday, 21 July 2007 4:35 AM
> To: 'Stark, Barbara'; 'Mary Barnes'; [email-masked]
> Subject: RE: [Geopriv] HELD comment on responseTime parameter
>
> Hehe
>
> As you know, I am in the binary "gimme what you got now, gotta route
> this
> call" or "I need a good location, I'll wait for it" camp.
>
> I have a really hard time coming up with a use case where you have a
> value,
> and not knowing anything about what the other end can do, I think a
> value is
> pretty useless.
>
> Please keep in mind that "right away" is order of milliseconds and
"I'll
> wait" can be 30 sec give or take for a typical assisted GPS start up,
> and a
> couple of minutes for a cold start GPS.  Right away is protocol
> request/response territory.  Anything that has tens of seconds or more
> in it
> is an async event notification/call back kind of thing.
>
> Brian
>
> > -----Original Message-----
> > From: Stark, Barbara [mailto:[email-masked]]
> > Sent: Friday, July 20, 2007 2:25 PM
> > To: Mary Barnes; [email-masked]
> > Subject: [Geopriv] HELD comment on responseTime parameter
> >
> > I'm probably opening a can of worms with this comment, but I'll make
> it
> > anyway...
> >
> > There have been discussions elsewhere as to whether it's really
> > useful/meaningful to specify a desired response time, or whether
it's
> > better to specify that the response is needed right away (presumably
> for
> > routing purposes) or the device can wait a little to get a more
> precise
> > location.
> >
> > Should we have that conversation here, about this parameter?
> > Barbara
> >
> > *****
> >
> > The information transmitted is intended only for the person or
entity
> to
> > which it is addressed and may contain confidential, proprietary,
> and/or
> > privileged material. Any review, retransmission, dissemination or
> other
> > use of, or taking of any action in reliance upon this information by
> > persons or entities other than the intended recipient is prohibited.
> If
> > you received this in error, please contact the sender and delete the
> > material from all computers. GA623
> >
> >
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
>
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>
>
------------------------------------------------------------------------
------------------------
> 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]
>
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

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

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

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

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Aug 2007 07:32:38 -0400

As I stated before, the basic IETF protocol design rule is that  
adding features requires rough consensus. I don't see such rough  
consensus here.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 07 Aug 2007 08:23:50 -0400

I thought that there was some agreement on the compromise proposal to 
keep the responseTime parameter, but make it optional and make the 
default to return ASAP.  Do people have disagreements with that?

--Richard

Henning Schulzrinne wrote:
> As I stated before, the basic IETF protocol design rule is that adding 
> features requires rough consensus. I don't see such rough consensus here.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Aug 2007 08:27:30 -0400

I don't know who agreed to this, beyond the parties that advocated  
for the parameter. I don't see it as necessary or helpful for the  
base specification. If this turns out to be truly necessary, this can  
easily be added as an extension later.

On Aug 7, 2007, at 8:23 AM, Richard Barnes wrote:

> I thought that there was some agreement on the compromise proposal  
> to keep the responseTime parameter, but make it optional and make  
> the default to return ASAP.  Do people have disagreements with that?
>
> --Richard
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 07:59:24 -0500

What is the objective measure of consensus then?

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 08:10:24 -0500

Hi Henning,

Can you please explain how, in the absence of such this feature, a LIS
that could provide an arbitrary level of accuracy over an arbitrary
period of time knows when it should return an actual result in response
to a HELD location request?

Cheers,
Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Aug 2007 09:58:54 -0400

As I believe Brian and I have explained, the client should be able to  
request "asap" and "agap" ("as good as possible"). If I understood  
Rohan correctly, he also alluded to a similar type of distinction in  
the world of medical labs.

As Brian noted, no useful location determination system has arbitrary  
time constraints, measured in hours. As I've tried to explain, since  
the client has no idea what the server's time-accuracy curve is,  
providing a time parameter is meaningless to the client.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 7 Aug 2007 14:14:08 -0500

This is what I believed that the consensus was also.

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, 7 August 2007 10:24 PM
> To: Henning Schulzrinne
> Cc: [email-masked]; Dawson, Martin; Mary Barnes
adding

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 17:13:58 -0500

Thank you for your forbearance.

What I'm asking is - what if there are three or more positioning methods
(or accuracy is determined in proportion to the time taken) the LIS
could invoke? Are you saying that a LIS should be constrained to only
two results by the semantics of the protocol? We already have the
situation in the real world where a wireless LIS will have more than two
methods of positioning.

I don't think the medical metaphor bears close examination. The
terminology is used in specific situations where the requestor knows
exactly what they are asking for and exactly how long it should take to
provide. It doesn't really say anything about this situation.

Rohan asked me for some use cases - I have provided them. I've also
asked for someone to provide use cases where a client would not impose a
timeout on a location request. I haven't had a response from any of
these and yet the suggestion was that use cases were pivotal to
progressing the discussion.

Cheers,
Martin

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 7 Aug 2007 18:02:30 -0500

We didn't reach consensus at IETF-69, per the minutes and the discussion
captured in the Jabber log (at the end):
http://www3.ietf.org/meetings/ietf-logs/geopriv/2007-07-25.html   
There were certainly folks that were okay with the compromise, but the
APP area advisor mentioned that the responseTime wasn't compatible with
HTTP architecture and she wanted more use cases.  And, the discussion
that has continued on the list since IETF-69 also doesn't seem to
indicate consensus had been reached (i.e., I didn't see the opponents
backing down and agreeing to the compromise).  I'm still struggling
myself to understand the use cases provided, as like others, I can't see
how the client can know what time is acceptable.  I understand that
there are locations that take varying amounts of time to gather and that
a client might have a particular preference for a more accurate location
depending upon the situation.  That all said, I don't object to the
current specification of the responseTime in the document, as it is
optional and quite loosely specified, for example: 
   "The value of this attribute is indicative
   only, the LCS is under no obligation to strictly adhere to the time
   limit implied; any enforcement of the time limit is left to the
   requesting Device."
and:
   "The LCS MUST provide the most accurate LI that can be determined
   within the specified interval.  This parameter could be used as input
   when selecting the method of location determination, where multiple
   such methods exist."
So, in the end, I can't see that it will do harm, but the concept of
time does seem arbitrary given the objective (to be able to get a
location with a certain level of accuracy).  

Mary

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, August 07, 2007 2:14 PM
To: Richard Barnes; Henning Schulzrinne
Cc: [email-masked]; Dawson, Martin; Barnes, Mary (RICH2:AR00)
Subject: RE: [Geopriv] HELD comment on responseTime parameter

adding

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 18:19:48 -0500

Thankyou Mary,

The objective isn't to get a specific accuracy. The objective is to tell
the LIS how long the client is prepared to wait for a result so that the
LIS can provide the optimal accuracy given that time constraint.

I don't understand the perspective that the client can't know what time
is appropriate. I think the client is the only one that knows how long
it is prepared to wait.

Having said that, I also think the nominal semantics were reasonable
and, at the very worst, benign. I gather that it's not popular to cite
experience in this area but my experience with LBS is that this will be
an extremely useful feature and not in the least negative.

Cheers,
Martin

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Wednesday, 8 August 2007 9:03 AM
To: Winterbottom, James; Richard Barnes; Henning Schulzrinne
Cc: [email-masked]; Dawson, Martin
Subject: RE: [Geopriv] HELD comment on responseTime parameter

Mary

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, August 07, 2007 2:14 PM
To: Richard Barnes; Henning Schulzrinne
Cc: [email-masked]; Dawson, Martin; Barnes, Mary (RICH2:AR00)
Subject: RE: [Geopriv] HELD comment on responseTime parameter

adding

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 7 Aug 2007 16:55:01 -0700

For what it's worth, I get the end-user use cases now, although I  
don't always understand the back-end architecture as it affects the  
information available and at what time delay,  and I don't yet see  
how the use cases dictate one particular architecture.

Here's my own use case variation that is neither "ASAP" or "AGAP":
	- Twitter users could have a location publishing and friend finding  
application, usually to be used on a mobile device, which may be a  
laptop, which may sometimes be connected to a physical network but  
sometimes be 802.11 and sometimes cell.  Ideally this application  
would get a civic location because "nearby" is different when you're  
in Northern Ontario or driving down a highway than when you're in  
downtown San Francisco on foot.   Coordinate location could be a  
fallback.
  	- For this application, when running as an unattended location  
publishing process, no timeouts are needed.  However when the user  
wants to do something active and the location is not yet known, users  
are willing to spend an average of seven seconds of wait time in  
order to avoid typing in a location manually.   For times above seven  
seconds, the application should just let the user type in a location.

This use case, like many others, could be handled a number of ways.
1.  The application to set its limit to "infinite" or "7s" depending  
on context, and send that limit in the location request to the  
server, aka the main proposal geopriv is considering
2.  This particular use case could be handled by asking for a civic  
location and drop the connection (or at least changing the UI to  
prompt text entry) if a time limit is reached.  If the civic location  
doesn't return within a few seconds the client could send a second  
request for geo, and the geo request could also be dropped.
3.  The client could ask the server what location information it has  
available and at what expected time delays in one request-- like  
asking for an index--  then in a second request ask for one of those  
location responses.  If all the times are too long, the client goes  
straight to text entry without even waiting seven seconds.
4.  Hybrids of the above solutions...

I'm sure there's more approaches, and I can't see how we could gather  
use cases in sufficient detail to really dictate a choice of approach  
since this is standards work, not a spec for one particular  
application.  I'm not sure further discussion on use cases is going  
to sway technical choices though it may sway consensus on whether to  
address the response time problem.

The question of what is easiest to do in HTTP, and what works best  
with proxies and other intermediaries, is somewhat more conducive to  
an answer, although the answer still varies depending on whether you  
have more or less control over the client or the server code bases.

The question of whether we have a consensus to address any response  
time use cases at all, or the question of what approach we have a  
consensus to use assuming the first consensus, is even more conducive  
to an answer, that is if we're ready to try to find that consensus.

Lisa

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Aug 2007 20:11:42 -0400

In your example, is the seven seconds a cold start time: you open your
laptop in a new location, and you will wait 7 seconds to avoid typing your
location manually?  If it is, then you have somewhat of a use case.   The 7
seconds will actually be useful for a "quick fix" kind of location measuring
system.  On the other hand, what accuracy do you need?  

Actually the biggest part of the problem is that we all understand there is
a speed/accuracy tradeoff, but somehow the proponents only want to talk
about speed.  I think there are many more use cases for a specified accuracy
than a specified response time.  

If 300 meters or so of accuracy is enough, then a quick fix might work.  If
you need to know an accurate civic location (street address), it won't work.

I think the Boolean is a good start.  I think 99% of applications will find
it acceptable.  I think we'll need an accuracy parameter before we need a
time parameter.

OTOH, I won't go to the mat on it.  If we need to compromise, I'll
compromise.  It's not that important; it's just, in my opinion, useless.

Brian

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2007 7:55 PM
> To: Mary Barnes
> Cc: [email-masked]; Dawson, Martin; Henning Schulzrinne
> Subject: [Geopriv] Response time use cases (was: HELD comment
> onresponseTime parameter)
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 19:18:54 -0500

Hi Lisa,

I think your use case is an excellent example of an application that
will make use of semantics for a fixed time response or an open-ended
response time (note, I think in the case of the latter, any realistic
implementation will still have a finite cap on the time it is prepared
to wait). I think the current proposal has a default "immediate"
response semantic as opposed to the "most accurate" semantic. I'd
suggested semantics to support both but I think Brian only felt the
"immediate" option was useful. I don't mind.

If we consider location determination technologies in the wireless
domain, it is not really possible to provide a prescriptive catalogue of
accuracies and latencies. The technologies are simply not that
deterministic. The ability to measure network signals, the time taken to
get a sufficient set of samples, and the time taken for algorithms to
converge is subject to unpredictable environmental conditions. Base
station hearability is influenced by both signal strength and
environment clutter and cell density. Further, the accuracy (and yield)
of any one technique also varies on a per-case basis.

A location server may invoke several measurement procedures concurrently
and get results from those over an unpredictable amount of time. It may
do a rapid rough location calculation based on serving base station
identity and then simultaneously commence sampling of uplink signals
while also providing GPS assistance data to the device and requesting it
to provide GPS pseudo-range measurements. The server is now equipped
with rough location and is waiting an arbitrary amount of time for two
separate measurement procedures to conclude. It may get an intermediate
result from one of those and still be waiting for an arbitrary period
for the other to conclude. The GPS fix may not occur at all if the
device cannot get a fix due to a poor acquisition environment.

At some point the server has to decide that it has done what it can and
return the best available result. The suggestion is to provide guidance
to the server so that it can do this. The client is in a position to
know how long is long enough but the server can't say what
accuracies/latencies are possible until after the positioning has been
performed - which is somewhat too late for the catalogue approach.

I'm not a fan of tying the application protocol semantics to the
session/transport protocol. HELD does not have to run on HTTP and I
don't like to think of applications having to be written differently
depending on which underlying protocol is used.

Cheers,
Martin 

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]] 
Sent: Wednesday, 8 August 2007 9:55 AM
To: Mary Barnes
Cc: Winterbottom, James; Richard Barnes; Henning Schulzrinne;
[email-masked]; Dawson, Martin
Subject: Response time use cases (was: HELD comment on responseTime
parameter)

	- Twitter users could have a location publishing and friend
finding  

Lisa

On Aug 7, 2007, at 4:02 PM, Mary Barnes wrote:

> ----------------------------------------------------------------------

> --
> ----------------------------------------------------------------------

> --

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 19:27:18 -0500

Again - experience is not considered relevant, however:

In cellular, accuracy is a well established QoS parameter in the
request. It is used for technology arbitration. However, every LBS we
have encountered wants the "strict-QoS" turned off for accuracy. That
is, if the requested accuracy cannot be returned, then they'd still like
to be given whatever result is available. Regardless, they all have
strict requirements about the maximum time that a result should take.

Since geodetic location should include uncertainty if accuracy is going
to be communicated, and civic addresses are at a self-evident level of
granularity, then the client is able to asses the result for themselves.

I actually think there is a significant qualitative difference with
respect to when things like desired response time and available accuracy
are known - and this is what empirical experience is highlighting.

I have no objection to having an accuracy QoS parameter Brian. I don't
consider it to be useful so I haven't been asking for it. If somebody
else thinks it would be useful to them, I wouldn't throw barriers in
their way. I do think that the semantics will need to be clear with
respect to how strict that criterion is. That is, should a result be
provided or not if the LIS cannot provide the requested accuracy.

Cheers,
Martin 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 8 August 2007 10:12 AM
To: 'Lisa Dusseault'; 'Mary Barnes'
Cc: [email-masked]; Dawson, Martin; 'Henning Schulzrinne'
Subject: RE: [Geopriv] Response time use cases (was: HELD comment

In your example, is the seven seconds a cold start time: you open your
laptop in a new location, and you will wait 7 seconds to avoid typing
your
location manually?  If it is, then you have somewhat of a use case.
The 7
seconds will actually be useful for a "quick fix" kind of location
measuring
system.  On the other hand, what accuracy do you need?  

Actually the biggest part of the problem is that we all understand there
is
a speed/accuracy tradeoff, but somehow the proponents only want to talk
about speed.  I think there are many more use cases for a specified
accuracy
than a specified response time.  

If 300 meters or so of accuracy is enough, then a quick fix might work.
If
you need to know an accurate civic location (street address), it won't
work.

I think the Boolean is a good start.  I think 99% of applications will
find
it acceptable.  I think we'll need an accuracy parameter before we need
a
time parameter.

Brian

finding
to
> >>> features requires rough consensus. I don't see such rough
consensus
> >> here.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 7 Aug 2007 19:30:23 -0500

I should have said, sorry Brian, thank you for being prepared to accept
the parameter anyway. I guess this is one data point for consensus that
passes Henning's non-advocacy test?

Cheers,
Martin 

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, 8 August 2007 10:27 AM
To: Brian Rosen; Lisa Dusseault; Mary Barnes
Cc: [email-masked]; Henning Schulzrinne
Subject: RE: [Geopriv] Response time use cases (was: HELD
commentonresponseTime parameter)

Cheers,
Martin 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 8 August 2007 10:12 AM
To: 'Lisa Dusseault'; 'Mary Barnes'
Cc: [email-masked]; Dawson, Martin; 'Henning Schulzrinne'
Subject: RE: [Geopriv] Response time use cases (was: HELD comment

Brian

finding
to
consensus

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Aug 2007 10:50:04 -0700

At 4:55 PM -0700 8/7/07, Lisa Dusseault wrote:
>For what it's worth, I get the end-user use cases now, although I don't always understand the back-end architecture as it affects the information available and at what time delay,  and I don't yet see how the use cases dictate one particular architecture.
>
>	- Twitter users could have a location publishing and friend finding application, usually to be used on a mobile device, which may be a laptop, which may sometimes be connected to a physical network but sometimes be 802.11 and sometimes cell.  Ideally this application would get a civic location because "nearby" is different when you're in Northern Ontario or driving down a highway than when you're in downtown San Francisco on foot.   Coordinate location could be a fallback.

Your statement "Ideally this application would get a civil location because "nearby" is
different..." doesn't quite make sense to me.  "Nearby" is a social measure that
does vary a lot (my grandparents' farm was 26 miles from our house in town and it
was "way out in the boonies"--too far for us to see them except some weekends;
I'll commute the same amount each way today), but that isn't really related
to how the locations are expressed.  My grandparents farm was the same
distance out in the boonies whether expressed as a distance, coordinates,
or civic location.

> 	- For this application, when running as an unattended location publishing process, no timeouts are needed.  However when the user wants to do something active and the location is not yet known, users are willing to spend an average of seven seconds of wait time in order to avoid typing in a location manually.  

Citation, please?  Or are you postulating this for the thought experiment?

>For times above seven seconds, the application should just let the user type in a location.
>
>1.  The application to set its limit to "infinite" or "7s" depending on context, and send that limit in the location request to the server, aka the main proposal geopriv is considering

The basic problem with this approach is that the server has no idea how much of
the time has already been consumed in other activities or will be consumed by
the return trip.  If the application expresses it as N seconds, based on some UI
constraint, the client has to lop off an arbitrary amount for network activity to correct
for that.   For something based on TCP where retransmission over a wireless link
may need  to occur before the data returned is actually presented to the
application layer,  deciding what to lop off is  a non-trivial problem.   
For one thing, I now have to  present some  basic idea of link characteristics to
the application.  Where do I stop with that? Does the appplication need to know the
link is tunneled via a VPN, as  well as the fact that it is 802.11?  Does it need to know
that the host is using triangle routing with MIP, rather than a locally assigned address?
Does the client presume that the other end of the flow is on a perfect, local link? 
Or presume it is some random place in the topology? 

You can ignore that, and build some general slop into the system.  In that case
7s becomes "soon" as opposed to "right now" or "whenever".

>2.  This particular use case could be handled by asking for a civic location and drop the connection (or at least changing the UI to prompt text entry) if a time limit is reached.  If the civic location doesn't return within a few seconds the client could send a second request for geo, and the geo request could also be dropped.

Dropping the connection would not make much sense here; at worst, the client
has a recent location to work with for the next prompt (especially valuable for
something that is nomadic, rather than truly mobile).  

>3.  The client could ask the server what location information it has available and at what expected time delays in one request-- like asking for an index--  then in a second request ask for one of those location responses.  If all the times are too long, the client goes straight to text entry without even waiting seven seconds

The problem is that the server may well not know this indexed data; it can, at most,
give general ranges of the time it *might* take.  If you wanted to add a parameter
to the "immediate fix" request that allowed the server to give estimates on what
the time for a complete request would be, I think that would be harmless, though
not terribly useful.  I think burning a round trip to ask for the estimates without
returning any location is likely to be a bad idea, though.

You're also missing the battery & data channel burn aspects of this.  A mobile
system could continually ask for this data pre-need, so that the application
can have it whenever it is wanted.  In a big-battery 802.11 equipped device,
it might even be willing to do so; the resulting use of data channel and battery
aren't that big a deal.  For a small, mobile device, though, that's not a great
use of either resource, and it is very unlikely.

			regards,
				Ted
>.
>I'm sure there's more approaches, and I can't see how we could gather use cases in sufficient detail to really dictate a choice of approach since this is standards work, not a spec for one particular application.  I'm not sure further discussion on use cases is going to sway technical choices though it may sway consensus on whether to address the response time problem.
>
>The question of what is easiest to do in HTTP, and what works best with proxies and other intermediaries, is somewhat more conducive to an answer, although the answer still varies depending on whether you have more or less control over the client or the server code bases.
>
>The question of whether we have a consensus to address any response time use cases at all, or the question of what approach we have a consensus to use assuming the first consensus, is even more conducive to an answer, that is if we're ready to try to find that consensus.
>
>Lisa
>
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Aug 2007 10:54:54 -0700

>passes Henning's non-advocacy test?

Consensus is often based on compromise.  Are you willing to compromise here?
At one side, we have a willingness for two times:  now and "when you have
a good answer" (for some value of good).  You and James are arguing for
arbitrary times to be supported.  Is there something between arbitrary and
2 that actually meets the real use cases here?  I think we can agree that
being able to express a time 2 years out is not useful.   Possibly we agree that
expressing a time as 1 or 2 seconds is so close to "now" in a system with
any network slop is not greatly different.  Are there any other constraints
we can put in here to avoid this turning into the protocol expressing a
constraint that the typical server simply will put into one of its general pools
of now, soon, and "when you know"?

				regards,
					Ted

---

From: "Stuard, Doug" <[email-masked]>
Date: Wed, 8 Aug 2007 17:19:40 -0400

I think specifying some value of "when" is often more important than
specifying some value of "good".

Knowledge of the server's time-accuracy curve is IMHO irrelevant. It is
what it is (or "are" where there are multiple location methods
available).  The client has his own time-accuracy tolerance curve based
on his application, which should govern ("The customer is always
right").  While accuracy is important, the key element is always time.
The client request would, in effect say: "I would like 10 meter
accuracy, and am prepared to wait up to a minute to get it.  If not
achieved by that time, give me the best you've got".  (I haven't seen
anyone say "I need x meters accuracy, and I am willing to wait however
long it takes until that is achieved."...there's always a time limit,
even if implicit).  

If the server can provide the requested 10 meter accuracy in 15 seconds,
it's done.  If not, it keeps working up to the one minute limit, then
provides its "best effort" response (possible including its accuracy
estimate).

For an emergency request for routing purposes (i.e., a "quick fix"), the
initial request would be something like: "I would like 500 meter or
better accuracy, and am prepared to wait no more than 3 seconds to get
it.  If not achieved by that time, give me an 'unable to locate' or a
'use default routing' message". (Alternately, it could be of the form:
"I need a location and associated accuracy estimate within 3 seconds
with whatever accuracy you can provide. If not achieved by that time,
give me an 'unable to locate' or a 'use default routing' message").   

Doug

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2007 1:55 PM
> To: Dawson, Martin; Brian Rosen; Lisa Dusseault; Mary Barnes
>(snip)
> a good answer" (for some value of good).

> Sent: Tuesday, August 07, 2007 9:59 AM
> To: Dawson, Martin
> Cc: GEOPRIV

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 8 Aug 2007 17:29:34 -0500

Hi Ted,

I have compromised as far as making the parameter optional and there
being default semantics for that case - which meets everybody else's
preference anyway.

I am not willing to compromise such that the LIS can only infer a binary
condition and I don't think there's a halfway house. That's actually not
a compromise; it's exactly what I'm saying isn't adequate. What if there
are three or more possible results at staggered intervals? How does the
LIS know when it should stop? Why aren't LIS implementors allowed to
have more than two ways of working out location - and users to
correspondingly benefit from arbitrary levels of accuracy rather than
just bad/fast and good/slow?

I don't think there is anything wrong with a server that only has two
speeds and converting a scalar time parameter into this "pool". It's
perfectly consistent with the semantics.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Thursday, 9 August 2007 3:55 AM
To: Dawson, Martin; Brian Rosen; Lisa Dusseault; Mary Barnes
Cc: [email-masked]; Henning Schulzrinne
Subject: RE: [Geopriv] Response time use cases (was: HELD

>passes Henning's non-advocacy test?

Consensus is often based on compromise.  Are you willing to compromise
here?
At one side, we have a willingness for two times:  now and "when you
have
a good answer" (for some value of good).  You and James are arguing for
arbitrary times to be supported.  Is there something between arbitrary
and
2 that actually meets the real use cases here?  I think we can agree
that
being able to express a time 2 years out is not useful.   Possibly we
agree that
expressing a time as 1 or 2 seconds is so close to "now" in a system
with
any network slop is not greatly different.  Are there any other
constraints
we can put in here to avoid this turning into the protocol expressing a
constraint that the typical server simply will put into one of its
general pools
of now, soon, and "when you know"?

				regards,
					Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Aug 2007 16:06:51 -0400

Currently, there is no way to specify the accuracy in the HELD  
document, so I'm confused by your comment. As I've mentioned, I have  
no objection to such an accuracy specification and have made an  
accuracy suggestion earlier, although I agree with others that it has  
its own set of issues.

As I mentioned in that earlier post, only the accuracy requirement  
matters. If I say "I need 100m accuracy for dispatch", I mean it -  
and timing out earlier doesn't help me. (Subject to the 30s-style  
system engineering restrictions that Brian has mentioned.)

In all emergency calling cases, after all, I want data as quickly as  
possible. If all I need is county-level accuracy for routing, I'm not  
interested in waiting some additional seconds, since these seconds  
just delay the response. If I was happy with a lower accuracy, I  
would have specified it - and probably issued two queries, one low- 
res to get the ambulance rolling in the right direction and one  
"agap", to find the cubicle.

If such a more elaborate accuracy specification turns out to be  
useful, I think it should be pursued as a separate extension draft,  
rather than having some half-baked solution that merely causes  
complexity and interoperability problems. As an extension draft, it  
can be appropriately scoped, labeled experimental as opposed to  
standards track or whatever the working group considers most  
appropriate.

As Brian, Ted and I continue to point out, we cannot think of a  
useful client time constraint that isn't completely arbitrary, beyond  
the "asap" value. No real-life, verifiable example of an application  
that has such time-only per-invocation constraints has been  
identified. (We all agree that providers of location information will  
likely be subject to upper-bound engineering constraints that they  
have to satisfy in order not to get into trouble with regulators and  
first responders.)

Also, a remark on "average" patience: At least in phone services,  
abandonment percentages tend to be exponentially distributed, i.e.,  
some people are very impatient, others wait forever. Thus, this tends  
to be not terribly helpful even if it could be experimentally  
determined.

Henning

On Aug 8, 2007, at 5:19 PM, Stuard, Doug wrote:

> --------------------------
> --------------------------
> [mf2]
>
>
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 10 Aug 2007 19:53:23 -0500

Hi Henning,

You continue to repeat the same incorrect statements and not acknowledge
any of the valid points that have been made. Use cases have been
provided. What is the point of people providing use cases if you just
dismiss them without commentary as "not realistic"?

Two questions you have not responded to and I insist you do

1. Please cite any real client-server request for location that would
not see the client imposing some time-out on the request.

2. Please explain how a LIS with 3 or more options for location
determination which trade off response time against accuracy could use
anything other than fast/bad or slow/accurate without this client
guidance.

If all we can get is the same general unsupported and academic
statements made over and over again then this discussion is obviously
going nowhere.

Brian, BTW, has agreed to the scalar parameter without acknowledging
himself to be a fan. I'd add the third question as to why you want to
prevent an, at worst, benign and always optional parameter if others
consider so strongly that it is valuable?

Regards,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Saturday, 11 August 2007 6:07 AM
To: Stuard, Doug
Cc: GEOPRIV WG
Subject: Re: [Geopriv] Response time use cases (was:
HELDcommentonresponseTime parameter)

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 10 Aug 2007 22:55:32 -0400

1. A PC boots and wants location for any application that may need it.  It
has no time limit in mind.  There is no sensible value for it to give.
Nothing times out until some app needs it.  When it asks for it, it has no
idea if that is 20 seconds, 2 minutes, 20 minutes, 20 hours or 20 days.

2. Time to deliver, as has been pointed out several times, it mostly a cold
start issue.  After a short time, most systems deliver updates fairly
rapidly.   The fact that the device has 26 ways to calculate location does
not mean the client cares.  It wants location now, or eventually.

Brian

> Sent: Friday, August 10, 2007 8:53 PM
> To: Henning Schulzrinne; Stuard, Doug
> Cc: GEOPRIV WG
> Subject: RE: [Geopriv] Response time use cases (was:
> HELDcommentonresponseTimeparameter)
> 
> Hi Henning,
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 10 Aug 2007 23:31:56 -0500

Brian,

As I have responded to this scenario several time now, and from experience in deploying these systems your summary is naïve and incorrect.

The application space where things will care about exactly this scenario is not the PC sitting on a desktop plugged into a DSL or cable line. It is a wireless solutions space, be that cellular, wiMAX or community WiFI. It is the situation where you have an application that needs location and then needs to do something with it, the subscribe notify doesn't matter, because without location the application fails. Not getting a response within 6 to 8 seconds results in such a degraded user experience that the application is no viable. Simply because you can't imagine such applications existing doesn't reduce their viability or peoples want for them.

The emergency case that you and several other keep suggesting as gimme the fastest you can, isn't true either, at least in the cellular space today it isn't. The cell-based routing that is often talked about here, is quoted in NENA and other circles as having 30% misroutes in the United States, and lead to enhancements in J-STD-036B to support fast-fix solutions for routing. Removing the repsonseTime parameter will result in this type of location fix not being available, as it clearly falls into the grey category between fast as you can, and as good as possible. Please don't try and tell me that this isn't a valid use-case because it is deployed today!

I have now described several VALID use cases where this parameter will be useful, none of the arguments presented against the inclusion of this parameter have indicated how this parameter is harmful and this is especially true with the agreed change in semantics.

Regards
James

> Sent: Saturday, 11 August 2007 12:56 PM
> To: Dawson, Martin; 'Henning Schulzrinne'; Stuard, Doug
> Cc: 'GEOPRIV WG'
> Subject: RE: [Geopriv] Response time use cases
> (was:HELDcommentonresponseTimeparameter)
> 
> > ----------------------
> > ----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 11 Aug 2007 00:39:35 -0500

So your implementation of this PC client would have it booting up,
sending a single request, and then waiting forever for a response?

That would be an extraordinarily bad implementation. If the request was
lost for any reason, you'd have to reboot the PC before another one
could be generated. And this particular niche use case is fine and dandy
while the other four that have been described are not realistic?

You've totally begged the question with the sly "..until some app needs
it." Clause of the scenario. Then what? What does it do then and how
long does it wait for the response? All you've done is punt the question
of the actual application requirements by inserting a spurious "PC"
agent in the middle of the request.

As has also been pointed out more than several times now - in mobile
access networks, location can only be meaningfully requested when it is
needed. Your cold-start PC scenario simply isn't applicable in a mobile
context.

"It wants location now, or eventually." - By what authority is this
premise justified? I know from personal experience that applications
want location within a given period of time and, generally, want the
best accuracy available in that time. They may state an accuracy
requirement but, if that can't be met, they always want what could be
determined anyway. My perspective is based on experience - whence the
axiom you cite?

Your premise also then, is that intermediate accuracy location
technologies should never be developed and never be given access from
clients?

You're arguing that UTDOA, OTDOA, RTT, EOTD, subsector-TA, Radio-camera,
and WiMAX scanning report integration are all invalid location
technologies because they are slower than a cell-based location
calculation but not as accurate as an arbitrarily protracted GPS
calculation? It's an amazingly narrow-minded perspective of location
technology.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 11 August 2007 12:56 PM
To: Dawson, Martin; 'Henning Schulzrinne'; Stuard, Doug
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Response time use cases (was:

1. A PC boots and wants location for any application that may need it.
It
has no time limit in mind.  There is no sensible value for it to give.
Nothing times out until some app needs it.  When it asks for it, it has
no
idea if that is 20 seconds, 2 minutes, 20 minutes, 20 hours or 20 days.

2. Time to deliver, as has been pointed out several times, it mostly a
cold
start issue.  After a short time, most systems deliver updates fairly
rapidly.   The fact that the device has 26 ways to calculate location
does
not mean the client cares.  It wants location now, or eventually.

Brian

---

From: <[email-masked]>
Date: Sat, 11 Aug 2007 11:49:43 +0100

I have not been able to follow all the discussions on the mailing list
but am aware "use cases" for a ResponseTime parameter are being sought.
Here's my example for emergency call handling.

As many will know, for UK emergency call handling, 999/112 calls from
all over the UK are initially answered in a stage 1 PSAP, which then
routes the call using location information, while at the same time
asking caller which type of service they want (Fire, Police, Ambulance
or Coastguard - the stage 2 PSAPs).  For this routing process we need
location as quickly as possible so as not to hold-up the call, but we
have about 5 seconds for "as quickly as possible" to work.

The call is then onward connected to stage 2 PSAPs who answer it
(hopefully within 10 seconds) and then start to question caller and
pinpoint the incident location.  

At this point the stage 2 PSAP call-taker really wants the most accurate
location possible displayed on their screen, though as they continue to
speak with caller for some time (around 2 minutes would be typical) they
can usefully accept location information throughout this time, though
clearly best to have it at outset.  Within next 8 - 20 minutes the
ambulance will be expected on site (UK targets). Call-takers obviously
cannot wait indefinitley for a location and will question caller to
establish it using whatever they have been provided with automatically.
[This timeline would be extended for a caller unable to speak, with
call-takers prepared to wait longer for a precise location (but not
indefinitely before trying other ways to find caller if there was major
concern)]  

What I'm trying to say is that a client making location requests from a
LIS (probably an "on behalf of" (OBO) enquiry for early implementations)
and using that location to (i) route and (ii) provide location to stage
2 PSAP does have at least a couple of time limits it works with.  One
could set these as (i) within 0 - 5 seconds for routing ii) within 15 -
60 seconds for pinpointing, then send 2 simultaneous queries to LIS with
different time limits in case there are different mechanisms that allow
a more precise location to be derived if you wait longer.   The OBO
client uses and forwards first location but would also forward second
location if one received of higher accuracy in a time within which it's
most useful.  The obvious case is cell ID (+ timing advance) available
quickly and some form of assisted GPS available after around 20 seconds
or so (I believe).  However I suspect that as access network location
techniques for different set-ups are established not all will be
instant, eg position within a campus (university LIS) useful to stage 2
PSAP, may take longer than knowing what town or county in which the
campus is situated (public network LIS)which is sufficient for Stage 1
PSAP..... 

I hesitate to write at this point (I'll have no email access now for 2
weeks holiday, when I'm not allowed to log-on!) as there may be
questions or comments.  I'll apologise now for lack of response from me
.....best regards

John   
 
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: 10 August 2007 21:07
To: Stuard, Doug
Cc: GEOPRIV WG
Subject: Re: [Geopriv] Response time use cases (was:

Currently, there is no way to specify the accuracy in the HELD document,
so I'm confused by your comment. As I've mentioned, I have no objection
to such an accuracy specification and have made an accuracy suggestion
earlier, although I agree with others that it has its own set of issues.

As I mentioned in that earlier post, only the accuracy requirement
matters. If I say "I need 100m accuracy for dispatch", I mean it - and
timing out earlier doesn't help me. (Subject to the 30s-style system
engineering restrictions that Brian has mentioned.)

In all emergency calling cases, after all, I want data as quickly as
possible. If all I need is county-level accuracy for routing, I'm not
interested in waiting some additional seconds, since these seconds just
delay the response. If I was happy with a lower accuracy, I would have
specified it - and probably issued two queries, one low- res to get the
ambulance rolling in the right direction and one "agap", to find the
cubicle.

If such a more elaborate accuracy specification turns out to be useful,
I think it should be pursued as a separate extension draft, rather than
having some half-baked solution that merely causes complexity and
interoperability problems. As an extension draft, it can be
appropriately scoped, labeled experimental as opposed to standards track
or whatever the working group considers most appropriate.

As Brian, Ted and I continue to point out, we cannot think of a useful
client time constraint that isn't completely arbitrary, beyond the
"asap" value. No real-life, verifiable example of an application that
has such time-only per-invocation constraints has been identified. (We
all agree that providers of location information will likely be subject
to upper-bound engineering constraints that they have to satisfy in
order not to get into trouble with regulators and first responders.)

Also, a remark on "average" patience: At least in phone services,
abandonment percentages tend to be exponentially distributed, i.e., some
people are very impatient, others wait forever. Thus, this tends to be
not terribly helpful even if it could be experimentally determined.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Aug 2007 12:28:55 -0400

> not see the client imposing some time-out on the request.

Brian cited examples, so I saw no need to add to those. I had also  
mentioned that almost all pre-call location determination calls will  
fall into this category. For in-call techniques, the client wants "as  
soon as I get a location useful for routing". Specifying a time that  
is smaller than that (unknown) necessary time is pointless and  
counterproductive.

Naturally, eventually anything will time out, if only because some  
TCP library will give up, but those timeouts are measured in multiple  
minutes, i.e., beyond interesting location determination times.  
Unfortunately, the client software generally won't know what these  
values are, so even if they mattered, the HELD client couldn't offer  
them. (Quick, what's the timeout in the OS you're using?)

> anything other than fast/bad or slow/accurate without this client

As you keep ignoring, the client has no way to know what it will get  
for different time-outs. In the cases I cited, the client wants a  
certain accuracy as quickly as possible and could care beans about  
the mechanism used. As I've also pointed out repeatedly, a timeout  
provides no sensible means to select the mechanism except by the  
equivalent of throwing darts.

> statements made over and over again then this discussion is obviously

Thanks for the helpful characterization. You have unfortunately never  
offered a logical description as to how a client would pick the  
timeout value except by random conjecture and the moral equivalent of  
"ASAP".

> consider so strongly that it is valuable?

Because I believe it to be misguided.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 11 Aug 2007 18:23:40 -0500

Henning,

I had already countered almost all of these arguments in my previous
email to Brian.

Please take a look at those and come back with something new.
As a summary:

1) Your emergency citation is incorrect in the wireless case.
2) Applications generally have BOTH a time and an accuracy constraint
3) Your discussion on the operating system is a call for no timeouts in
any applications ever. Please tell me that you don't seriously believe
this?
4) timeouts for applications are based on empirical data, so yes, they
do no how long to wait, yes there is not guarantee that the location
will be better, but there is a very good chance that it will be.

I for one don't see applications waiting minutes for location responses,
so if the issue can be resolved with putting an upper bound on the
responseTime then I am happy to set that in the schema to say a minute.

I don't believe that this is misguided, I put this into the same
category of proposals that I and others have put into this forum such
as: an application layer location acquisition protocol, local service
discovery, location by reference. All things that I have had to fight
very hard over the last 2 and half years to get accepted because a small
group said they were misguided!

Regards
James

> Sent: Sunday, 12 August 2007 2:29 AM
> To: Dawson, Martin
> Cc: GEOPRIV WG

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 11 Aug 2007 20:10:46 -0500

Henning,

Taking each of your points in turn:

" Brian cited examples, so I saw no need to add to those."

Brian cited *an* example. It was that a cold start PC would send a
single location request and then wait forever or until the next reboot
for a response. This highlights what is wrong with the proposition. Of
course the PC would apply a timeout to the request and not wait forever
(and it would be an equally bad implementation to rely on the TCP layer
to indicate the timeout).

" As you keep ignoring, the client has no way to know what it will get  
for different time-outs."

This is very untrue; I have been giving it full attention. The answer is
that the client knows that it will get the best accuracy available
within that time. That is what the client knows and that is all they
need to know. You appear to be incapable of understanding that. What you
keep ignoring is that location determination is not a two speed process
and your approach forbids optimal location accuracy being provided.

" As I've also pointed out repeatedly, a timeout  
provides no sensible means to select the mechanism except by the  
equivalent of throwing darts."

I find this particularly bizarre. What is your citation for this claim?
I have already described how this is exactly used for selecting between
multiple technologies in wireless. You have selective hearing.

" You have unfortunately never  
offered a logical description as to how a client would pick the  
timeout value except by random conjecture and the moral equivalent of  
"ASAP"."

I offered use cases where the timeout is governed by what is sensible in
the application context - A "local information" service, an "interactive
location based game" environment, "a call routing secenario", "a
dispatch scenario". In all of these the applicable timeout is what makes
sense in the application and criteria such as whether there is visual
feedback to the user.

It has been indicated that, in point of actual fact, that cellular call
routing is determined with a specific timer being applied to the network
initiated location request from the MSC to the SMLC. The MSC sets the
timer based on what the operator, in consultation with the emergency
services, thinks is the optimal amount of time to do location
measurement for call routing. The tradeoff is time to do call-setup
against number of errors in PSAP routing. This timer tells, for example,
a UTDOA based SMLC how long it should spend taking uplink timing
measurements before sending a result. The longer it takes the more
accurate it will be. ASAP means don't take any measurements at all and
return the location based on cell. It's useless. Your approach means
that there could never be anything other than emergency call routing
using cell-level granularity.

I consider all your objections to be invalid or duly addressed.

Regards,
Martin

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 13 Aug 2007 20:11:27 -0400

James,

In an attempt to try and follow your thread.....
 
> The emergency case that you and several other keep suggesting 
> as gimme the fastest you can, isn't true either, at least in 
> the cellular space today it isn't. The cell-based routing 
> that is often talked about here, is quoted in NENA and other 
> circles as having 30% misroutes in the United States, and 
> lead to enhancements in J-STD-036B to support fast-fix 
> solutions for routing. Removing the repsonseTime parameter 
> will result in this type of location fix not being available, 
> as it clearly falls into the grey category between fast as 
> you can, and as good as possible. Please don't try and tell 
> me that this isn't a valid use-case because it is deployed today!
> 

Are you suggesting:

1) The MSO requests a finite time of the GMLC/MPC

Or

2) The GMLC/MPC requests a finite time of the PDE.

Just curious,

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 13 Aug 2007 19:50:25 -0500

Hi Marc,

Just to clarify the analogy. In the cellular world it is the MSC that
detects and invokes the emergency application and does something. In the
Internet world we have been talking about the end-point doing this. The
end-point detects the emergency call, does the location request and
dispatches the call. So the emergency application has to know how long
to wait, and this is NOT going to be ASAP unless you want to regress to
pre-BCP cellular standards.

I hope this helps.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Tuesday, 14 August 2007 10:11 AM
> To: Winterbottom, James
> Cc: 'GEOPRIV WG'
> Subject: RE: [Geopriv] Response time use
> cases(was:HELDcommentonresponseTimeparameter)
> 
> James,
>

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 13 Aug 2007 21:01:10 -0400

James,

OK, I may have misunderstood your original message.  I thought you stated
that in the cellular world, some entity be it MSC/GMLC/MPC/ALI steering
actually put a hard number response time constraint in it's request for
location/routing.  I was looking for more information on what/when/how, etc.

Does this happen?

Thanks,

-Marc- 

> Sent: Monday, August 13, 2007 8:50 PM
> To: Marc Linsner
> Cc: GEOPRIV WG
> Just to clarify the analogy. In the cellular world it is the 
> MSC that detects and invokes the emergency application and 
> does something. In the Internet world we have been talking 
> about the end-point doing this. The end-point detects the 
> emergency call, does the location request and dispatches the 
> call. So the emergency application has to know how long to 
> wait, and this is NOT going to be ASAP unless you want to 
> regress to pre-BCP cellular standards.
> 
> I hope this helps.
> 
> Cheers
> James
> 
> > > The emergency case that you and several other keep suggesting as 
> > > gimme the fastest you can, isn't true either, at least in the 
> > > cellular space today it isn't. The cell-based routing 
> that is often 
> > > talked about here, is quoted in NENA and other circles as 
> having 30% 
> > > misroutes in the United States, and lead to enhancements in 
> > > J-STD-036B to support fast-fix solutions for routing. 
> Removing the 
> > > repsonseTime parameter will result in this type of 
> location fix not 
> > > being available, as it clearly falls into the grey 
> category between 
> > > fast as you can, and as good as possible. Please don't 
> try and tell

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 13 Aug 2007 20:20:39 -0500

Hi Marc,

The MSC sets a QoS parameter in the PLR to the SMLC. This translates to
a hard-timeout in the MSC, and may translate to a different timeout in
the SMLC since the type conveyed is enumerated and not literal. Literal
would certainly reduce interop problems between vendor equipment.The
point is that yes it does happen, and the selected values are based on
empirical data.

If you want to learn more you really need to go and read J-STD-036B.

Cheers
James  

> Sent: Tuesday, 14 August 2007 11:01 AM
> To: Winterbottom, James
> Cc: 'GEOPRIV WG'
> location/routing.  I was looking for more information on
what/when/how,
> etc.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Aug 2007 19:32:49 -0700

> Am I overly optimistic?

Yes - I don't think I saw anyone change their opinion on this thread.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 13 Aug 2007 23:34:03 -0500

Hi Cullen,

There are certainly some people who haven't changed their stated
opinion. As ever, despite the consensus theory, any given thread in
Geopriv seems to have 90% of the emails generated by 3 or 4 people, the
rest by one or two others. Who knows what the majority view is? It's
easy to suspect that most subscribers don't actually read the thread,
let alone have an opinion.

So, procedural conundrums aside - and given you've stuck your head over
the trench :) - What do you think?

In particular, how do you recommend the following be addressed?

"A LIS has three or more methods of location determination, or a single
method of location determination, where accuracy improves the longer the
response time that is incurred. How does a LIS know which method to use,
or how long to spend on a given method?"

Henning's response is that this is not a real issue even though it is
demonstrably the case in wireless deployments today*. Actually, I
wouldn't care about this topic except that I do know it's a real issue.
Brian has avoided answering the question I believe.

I suggest the following definition for an optional parameter. Let's call
it "within".

"This parameter provides a quantified value for the time in which the
client would like to get a location result. The LIS may use this value
to determine the method of location determination and to provide the
optimum accuracy given this guidance. The LIS may take longer than the
indicated time to provide a response but cannot assume that the client
will be able to make use of the result. If the parameter is not
provided, then the LIS should assume that a response is required
immediately and the fastest available method of location determination
should be invoked."

I'm agnostic about the last sentence - in particular whether the default
actually means ASAP or MostAccurate. I don't think the detractors of
this parameter are particularly consistent on this point either. I'd
actually suggest that explicit semantics should be defined for both ASAP
and MostAccurate to eliminate the guesswork. I think only one of them
can be the default...

Cheers,
Martin

* Ever the useful resort of the dogmatist, this could be termed the "I
reject your reality and substitute my own." ruse. (with apologies to
Adam Savage) :)

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Aug 2007 09:31:14 -0400

The answer to your question is that if a quick fix is available (1-2 sec)
you use that to respond to ASAP, you use the most accurate response for the
rest. 

I have a counterproposal:
The protocol gets an optional mechanism where the server can return an
enumerated list of determination mechanisms with the accuracy and response
time of each.  The query has an optional parameter that selects one.  This
parameter has two predefined values for "ASAP" and "accurate" which are
mapped into the server's choice of the most appropriate mechanisms it has.

If determination mechanism has a time/accuracy tradeoff, the enumerated list
includes a a slope and intercept of a straight line approximation of the
tradeoff.  The query has an optional parameter for the point on the curve it
wants.

The design of the mechanism must be such that the client can completely
ignore all of it everything except the "ASAP" and "accurate" values.  The
server can also not implement the enumerated list, but must implement
ASAP/Accurate if it has the capability to provide different mechanisms.

Brian

> Sent: Tuesday, August 14, 2007 12:34 AM
> To: Cullen Jennings

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 14 Aug 2007 08:40:48 -0500

Maybe there is a troll in our midst after all...

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 14 August 2007 11:31 PM
To: Dawson, Martin; 'Cullen Jennings'
Cc: [email-masked]; 'Mary Barnes'
Subject: RE: [Geopriv] HELD comment on responseTime parameter

The answer to your question is that if a quick fix is available (1-2
sec)
you use that to respond to ASAP, you use the most accurate response for
the
rest. 
[[MCD]] Which would completely fail to satisfy the routing requirement
for E911 in wireless access - because ASAP is not accurate enough and
most accurate is too slow. Which has been stated a lot of times now. Do
you think this is an acceptable limitation? Because the cellular E911
industry, including emergency services, didn't think so.

I have a counterproposal:
[[MCD]] I'm going to assume for the moment that this ghastly contrivance
is just proposed in jest. It will achieve nothing of value over just
letting the server know what the client response time expectation is.
And it displays more idealistic ignorance of the indeterminate nature of
actual wireless location technologies.

The protocol gets an optional mechanism where the server can return an
enumerated list of determination mechanisms with the accuracy and
response
time of each.  The query has an optional parameter that selects one.
This
parameter has two predefined values for "ASAP" and "accurate" which are
mapped into the server's choice of the most appropriate mechanisms it
has.

If determination mechanism has a time/accuracy tradeoff, the enumerated
list
includes a a slope and intercept of a straight line approximation of the
tradeoff.  The query has an optional parameter for the point on the
curve it
wants.

The design of the mechanism must be such that the client can completely
ignore all of it everything except the "ASAP" and "accurate" values.
The
server can also not implement the enumerated list, but must implement
ASAP/Accurate if it has the capability to provide different mechanisms.

Brian

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Aug 2007 17:23:07 -0700

> let alone have an opinion.

You are probably right - makes it a challenge for the chair to  
determine consensus but the high bandwidth meeting time where people  
can talk about this does help.

> the trench :) - What do you think?

Mostly I think that I should have kept my head firmly stuck in the  
mud at the bottom of the trench :-)

> or how long to spend on a given method?"

(as an irrelevant side note, I suspect that by LIS you mean something  
with significantly more functionality than I would meant but LCS but  
I will more or less read LCS where you write LIS because I don't  
think it makes much difference for the topic at hand)

Also you mention the following

> industry, including emergency services, didn't think so.
So, just hypothetically let me assume that three methods that take  
small, medium, and large amount of time and that only one of these  
(medium) will be usable for E911 calls.

I get that you are saying "The LCS needs to know which one of these  
to use and response time could be used to choose". I think Brian (and  
others) are saying the phone has no idea what is the right value to  
put in the responseTime parameter for a E911 call. Now I understand  
different application would have different requirements but none the  
less we do need to make sure that at least this E911 application is  
implementable on both the phone and LCS side.  You have proposed text  
of what the server would do with this parameter but it might help if  
you tried to propose text that explained what phone implementers  
should do to set the responseTime value for the specific E911  
application. It might also help if people thought about if all  
applications had only time based constrains, or if they had accuracy  
constraints, or if some applications really needed to know what the  
server could provide to pick which set of tradeoffs to take.

A few people have proposed solutions of the form: The server returns  
the quickest answer possible along with information about other  
answers that can be returned and allows the client to pick the one  
that is right for it. This also allows things like users interfaces  
feedback about remaining time till an answer is received. You seemed  
to think this sort of design would not work but I did not really  
understand why not. It might be useful to explain that.

Ted's email thread seemed like path that might lead to a good  
understanding of the solutions. I'm not sure that any of my questions  
are really worth replying to if the thread Ted started can help get  
to a good understanding of the solution space.

Cullen <with my individual hat on>

PS. - I don't have an opinion on if any particular design is the  
right one or not but the earlier threads did not really enlighten me  
enough that I can say I understand why it should be one way or the  
other. I suspect I am not the only one that feels that way.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 14 Aug 2007 19:52:04 -0500

Hi Cullen,

Thank you - and you've still got your head :)

My quick response is:

I think the client *has* to know what the application for the location
is. If the client is implemented as an "agent" on the device through
which other applications query, then that agent needs to support an API
through which the applications can prescribe the sensible response time.

If the client doesn't know what response time is appropriate then it's
not going to know any more if the LIS replies with some information
about a better location being available if you'd like to hang around.

If the client doesn't know how quickly it needs location then all bets
are off. It also can't say whether ASAP or "MostAccurate" are
appropriate.

Cheers,
Martin

Oh - you're right LIS means exactly the same thing as LCS.
(LCS=LIS=LS+LG) I use the term because LIS is what is used in the
vernacular in the rest of the industry. I think all the regulars in
Geopriv understand this but occasional visitors from the wider industry
do not. LCS was coined relatively recently - and for no apparent useful
purpose that I can fathom. The term "configuration" was only ever
adopted to resonate with DHCP - and despite the fact that location isn't
being "configured" in the same sense that a host is being "configured".
I like "LIS", people outside Geopriv know what it means, it can be
pronounced, and it doesn't have the namespace collision that LCS has
with 3GPP. Call me an oddball - but I'll keep using it.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Aug 2007 19:46:14 -0700

> Thank you - and you've still got your head :)

An issue that people are working on correcting :-)

> through which the applications can prescribe the sensible response  

Sure, makes sense, but I think my question is much more naive and  
simple minded. Assuming you have all this, what is the right time to  
put in for the E911 application? How many seconds? Does it change in  
different situations?

> about a better location being available if you'd like to hang around.

Hmm - this point has not been obvious to me. You could be right - I'm  
just trying to still get my head around this. Take for example the  
GPS navigation system in my car. Imagine it was getting it's location  
not via GPS but via this protocol. This particular application is  
totally useless unless it gets a location so there is no point  
returning until a location is available. Would it put more or less  
infinity in the  time? On the other hand, once it have a location  
with a hundred meters or so it is typically pretty useful so it  
certainly does not want to wait for some estimate that has a 99%  
change of being within 0.2 meters. I'm not going anywhere with this  
argument other than trying to explain some of the things that cloud  
the issue for me on the hope that folks on this list can provide  
clarity. Again, for this specific application, as an implementor of  
the client, I really don't know what I would put in the responseTime.  
Suggestions?

> Oh - you're right LIS means exactly the same thing as LCS.

No worries here but I think we still might be talking pas each other  
a little. I suspect you and I think of a LIS as about the same thing  
since I got my definition of it from some excellent book called "IP  
Location" but I think of the LCS having much less functionality than  
a LIS. I suspect you view LCS functionality as being roughly  
equivalent or the same as LIS. I don't think any of this matters for  
the conversation about responseTime but later we will have to be  
careful with the terms to make sure everyone is clearly understanding.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 14 Aug 2007 23:30:04 -0500

Viz the GPS navigation example...

It's also true that a car navigation system is not useful if the
location takes so long to come back that you've driven past your turn
off before your update arrives. Both time and accuracy are important in
this use case. 

Location updates are absolutely required within a specific period. Even
GPS-based systems use accelerometers and gyros to "fill in the gaps"
between GPS fixes. The fully integrated ones also use the car's
speedometer. They also use knowledge of the route and the limited
choices of where the vehicle can be based on the assumption that it's
actually on the road. They also know that all this information becomes
stale - the predictive location eventually diverges from reality if an
objective "correction" is not received soon enough. How soon is soon
enough depends on things like how fast the vehicle is travelling, how
wiggly the road is and how many options exist for branching from a
nominal route. The application would need to consider all these factors
in determining the necessary update time.

A properly functioning car navigation system has to be strict about this
response requirement. If the necessary accuracy simply cannot be
provided by the network location service in that time then that network
location service is not adequate for the car navigation application.
That's not a problem with the semantics that's just the reality of a
physical limitation.

As an aside, I would not think an IP network location service can
currently sensibly supersede native GPS augmented with accelerometers
and gyros with route-based constraints. The issue with using a wireless
network location service for car navigation today is that the state of
the art cannot support that application. Maybe, one day, an IP access
network will be able to offer the same characteristics; it would
probably need to be coupled with an overlay terrestrial based beacon
system. Its main advantage over GNSS (GPS, Galileo, etc) would be if it
provided more reliable coverage in the dense metro and etc environments
that cause acquisition problems for GPS today.

Viz the emergency call from the phone...

How does the phone know what time is right? There's a BCP being written
in ECRIT at the moment which is specifying exactly how long should be
spent in different phases of the call. The emergency call application on
the phone has to be based on this BCP (otherwise why do we have it?).
Currently we don't have any HELD mechanism to tell the LIS that it's a
request for emergency calling purposes - so the LIS doesn't have any
opportunity to invoke the BCP. I don't recommend such a mechanism for
this purpose; again, for this to work, the client would still have to
know it's an emergency application so knows what the appropriate time is
etc. etc.

Cheers,
Martin

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 15 Aug 2007 12:59:51 -0400

So long as I can have really simple rules for emergency call
applications, I'm happy. I want to be able to have really simple rules
for devices and for the LIS. I regret to admit, the devices and network
elements I specify don't tend to do a lot of "thinking" and don't really
"know" much, outside of what I tell them. And since I don't know or
think too much (if I can help it), that makes them pretty limited.

As has been mentioned, the longer the time the application may be
willing to wait, the more likely it is that other time-outs (e.g., open
port in a NAT) will time-out first. Right now, I don't realistically
expect http ports without traffic to stay open for too long, in a NATted
consumer environment. I'm thinking it's best not to bet on anything over
60 seconds in this environment. And I know I don't have enough knowledge
or thinking ability to intelligently design an app that can properly
determine a good value that's less than 60 seconds, other than "ASAP".
I'd be a little worried if my app somehow knew this, when I sure don't.
But, since I recognize that HELD can be used in other environments for
other applications, I have to step beyond my dumb NATted consumer bias
and admit that I really don't care. So long as I can have my simple,
unthinking, un-knowing rule. And so long as we keep the text that says
my LIS (or whatever the heck it's called) is allowed to use this value
as something that provides guidance, rather than as an absolute limit (I
prefer not to think too hard about LIS specifications, either). Under no
circumstances, can I accept something that forces additional complexity
on me. Optional complexity is ok. I'll just opt out.

I hope somebody cries "uncle" soon on the current debate, so we can get
on with some new and more exciting challenge. Maybe we can discuss how
to deal with "accuracy vs. response time" needs in relation to
references, rather than HELD. That would be such fun -- I'm really
looking forward to it.
Barbara

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Fri, 17 Aug 2007 09:17:18 -0600

As HELD appears (to me anyway) to be application independent, and given that 
there is strong dialogue for/against/ambivalent for the parameter, I would 
suggest that you make responseTime optional. Guaranteed that if you do not 
include this parameter, then one or more developers will ask for this 
parameter in a very short period of time. Even more so as the LG could be 
any sort of location enabled sensor, any mobile device whose location can be 
determined by triangulation, GPS etc, and so forth. From my geo perspective, 
the LG does not have to be part of the communications network or 
infrastructure.

FYI, we learned the hard way regarding time in the development of GeoRSS: 
The initial version of GeoRSS had geometry (GML) and feature description but 
no time. The first enhancement requested was for temporal elements.

Regards

Carl

----- Original Message ----- 
From: "Stark, Barbara" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>; "Dawson, Martin" 
<[email-masked]>
Cc: "GEOPRIV" <[email-masked]>
Sent: Wednesday, August 15, 2007 10:59 AM
Subject: RE: [Geopriv] HELD comment on responseTime parameter

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 17 Aug 2007 16:52:02 -0500

Thanks Carl,

I could not agree with you more. From one location application deployer
to another experience speaks volumes.

Cheers
James

> From: Carl Reed OGC Account [mailto:[email-masked]]
> Sent: Saturday, 18 August 2007 1:17 AM
> To: Stark, Barbara; Cullen Jennings; Dawson, Martin
> Cc: GEOPRIV
> As HELD appears (to me anyway) to be application independent, and
given
> any sort of location enabled sensor, any mobile device whose location
can
> be
> The initial version of GeoRSS had geometry (GML) and feature
description
> but