Subject: Re: [Geopriv] The "cold start" myth and the general solution

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 13 Aug 2007 19:14:47 -0400

I believe your answer summarizes to "I have no idea, it depends on network knowledge of which the client is clueless"

In no part of your answer did the application have any needs other than the patience of a user.  That is my point, applications don't have time parameters that have any meaningful content.  Its a handwave.  The server, on the other hand, actually knows something: like how long it will take.

Brian
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
[email-masked]

----- Original Message -----
From: Dawson, Martin <[email-masked]>
To: Brian Rosen <[email-masked]>; GEOPRIV WG <[email-masked]>
Sent: Mon Aug 13 18:25:04 2007
Subject: RE: [Geopriv] The "cold start" myth and the general solution

Well - thanks for pulling my pristine new thread back to the previous topic... :)

I don't think cold-start GPS is applicable to the discussion, particularly if it's autonomous GPS. We're talking about network provided location in the context of HELD. Note - I'm not saying autonomous GPS isn't a valid location technology.

<br> "Suppose you were writing code for a possibly mobile handset that
      Supported location based calling.  What is the value you put in
      your field?
    * You don't know if you are mobile
    * You don't know if there is a cold start issue
    * You don't know what the purpose for the location based call is

     What is the value, in seconds, that you recommend?  How did you
     come up with it?"

There's two approaches to answering that question from an implementer's perspective.

One is to ask how long are you really prepared to wait for a response before you go into exception handling. The user "dials" a specific destination and, by whatever means, the device decides it's a destination that requires location-based routing. You've included the constraint that the device doesn't know the appropriate time to delay the call setup for individual destinations. This means it has to apply a common timeout. The timeout that you apply is going to be driven by the boundary conditions you apply. Do you want the device to wait as long as is reasonable because you *really* don't know how accurate the location needs to be for any one of the possible destinations, or do you set a lower value based on how long you think the user is really going to wait? If you decide the former, then I would suggest that a minute is enough time to expect an ultimate-accuracy answer. If you decide the latter then I would suggest 10 seconds - though that will depend on what sort of feedback the user has with respect to whether the device is in an auto-locate procedure and that the call is pending. If there's feedback then the implementer may decide this can be longer.

The other approach, as an implementer who goes to the trouble of understanding the market, is to add some contextual knowledge about how long networks typically do take to return location information and to what accuracies. In addition, there'd be some research that correlates this with the typical requirements of location-based call routing demands. If you did that, you'd potentially come to the conclusion that given that the technology deployed in public networks is driven by the need to support emergency service with a fast-fix suitable for routing available in under five seconds and, similarly, this is actually all that any known location-based commercial call routing service needs. In that case, I would expect the implementer to set the timeout to 6 seconds. Most calls, in practice, will get the location back in under a second.

If you have a very specific need for highly accurate location in your application, then the implementer needs to recognize that this could take anything up to a minute - given the state of the art. I would recommend that the implementer make sure that the necessary human factors are included to provide the user with sufficient feedback as to what is going on while that request is being processed. I would not recommend that the implementer try to treat this application as if it were one that *expects* location to be returned in two seconds.

At no time, as an implementer, would I consider it sensible to build my application such that it waits forever. If the interface includes a function for the user to intervene (cancel the location procedure) then I'd set the timeout to something very large. Even then, based on the state of the art for public networks, I'd probably set it to only five minutes.

If I have a very specialist application in a completely proprietary private network with an arcane location determination technology - for example, my HELD client is a nano-bot measuring quantum fluctuations over many hours, then I'd expect to apply my own domain knowledge to the question of defining the timeout (maybe 365 days or until my research budget expires).

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 14 August 2007 3:17 AM
To: Dawson, Martin; 'GEOPRIV WG'
Subject: RE: [Geopriv] The "cold start" myth and the general solution

Cold Start is a one time startup which is the result, typically of GSP
satellite acquisition.  After cold start, updates come fast.  

The PC has no idea how long to wait.  It doesn't know when an app will
actually need location.  It may be shortly after startup, it may be minutes,
hours or days later.   It doesn't know (and doesn't care) if it's mobile or
not.  It might be.  

The PC client is a good example because it's power profile is a lot
difference from a handset.  If it had a GPS, it would typically leave it on,
even if no apps were using it.

The ONLY app that I know of that it sensitive to cold start is the emergency
call case.  Most other apps tolerate start up fine, because the app just
waits for cold start to be over, and then runs.  Typical examples would be a
navigation app.

One that is not yet common, but would have a cold start issue would be
location based calling other than emergency calls.

Let's look at that.

Suppose you were writing code for a possibly mobile handset that supported
location based calling.  What is the value you put in your field?
* You don't know if you are mobile
* You don't know if there is a cold start issue
* You don't know what the purpose for the location based call is

What is the value, in seconds, that you recommend?  How did you come up with
it?

Brian.

________________________________________
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Saturday, August 11, 2007 9:38 PM
To: GEOPRIV WG
Subject: [Geopriv] The "cold start" myth and the general solution

Hi all,

I thought it best to break this discussion topic onto a separate thread.

The "cold start" approach was cited as an exemplar scenario in a recent
post. This is where a computing device acquires its location once and then
uses that for every location application until reboot or the device changes
its network attachment.

It was Brian R who used the scenario - which is fine - but I'd also like to
acknowledge that Brian is the source of the very good use case where the
device is attached to a LAN which is itself mobile. Brian talks about an RV
driving down the interstate which has a LAN and which uses a wide area
wireless Internet access (e.g. 3G, WiMAX) from a public provider. The mobile
WiFI access point that Avis now rents out is another example, and WiFi LANs
are also available on train services in those places lucky enough to have
such facilities (I'm confident it will become commonplace in the short
term).

A device using an Ethernet cable or WiFi network adaptor has no way of
knowing what the actual nature of the Internet connection is. It is wrong
for a device which booted up and found itself attached to one these layer
two services to *assume* that cold start was a valid approach. Yes, a
desktop PC with an appropriately knowledgeable user could be configured to
correctly make this assumption. This relies on the device obtaining the
knowledge from an outside source (a user) but it's not inherently readily
discoverable from the network.

User configuration implies a default configuration. What is the safest
default configuration for a HELD client? It is to assume that the device
*could* be mobile and that it is best to request location at the time that
it is needed. As I'm sure everyone appreciates, it's common for computers to
operate in perpetuity on the default settings and, even if they are changed,
it is common for settings to not be adjusted when circumstances change.

Obtaining a cold-start location (or even periodically requesting a refresh)
is not harmful in itself. Indeed, it is good to obtain and cache a "last
known" location so that a given application can decide for itself whether it
is happy to use that if an immediately updated result isn't available.
However, even if it might not cause a problem in the 90% of DSL/cable
connected static devices, it is not a good general approach - and the
general approach of requesting location when it is needed covers the static
situation anyway.

Cheers,
Martin

Martin Dawson
Andrew Network Solutions Asia-Pacific
Email: [email-masked]
Phone: +61 2 42212992
Fax: +61 2 42212901
Mobile: +61 412 120300

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.

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

------------------------------------------------------------------------------------------------
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: "Dawson, Martin" <[email-masked]>
Date: Mon, 13 Aug 2007 18:31:08 -0500

Well, Brian, at this stage I've given umpteen examples that show how the
application does know how long it is prepared to wait. You keep
repeating the tired refrain - presumably you'll never change the tune.
You insist that as a client implementer, you would not have a request
timeout. I think you are a bad client designer if that is the case. You
apparently feel it is too much effort for an application developer to
actually think about what is sensible before implementation. Ditto.

The network cannot know anything about the use of the location
information, what response time is satisfactory or, even, what accuracy
is suitable. Only the client knows that.

You have stated in the past that you are still OK with the response time
parameter being specified. Are you still of that view?

Cheers,

Martin

________________________________

From: Rosen, Brian [mailto:[email-masked]] 
Sent: Tuesday, 14 August 2007 9:15 AM
To: Dawson, Martin; [email-masked]; [email-masked]
Subject: Re: [Geopriv] The "cold start" myth and the general solution

I believe your answer summarizes to "I have no idea, it depends on
network knowledge of which the client is clueless"

In no part of your answer did the application have any needs other than
the patience of a user.  That is my point, applications don't have time
parameters that have any meaningful content.  Its a handwave.  The
server, on the other hand, actually knows something: like how long it
will take.

Brian

----- Original Message -----
From: Dawson, Martin <[email-masked]>
To: Brian Rosen <[email-masked]>; GEOPRIV WG <[email-masked]>
Sent: Mon Aug 13 18:25:04 2007
Subject: RE: [Geopriv] The "cold start" myth and the general solution

Well - thanks for pulling my pristine new thread back to the previous
topic... :)

I don't think cold-start GPS is applicable to the discussion,
particularly if it's autonomous GPS. We're talking about network
provided location in the context of HELD. Note - I'm not saying
autonomous GPS isn't a valid location technology.

There's two approaches to answering that question from an implementer's
perspective.

One is to ask how long are you really prepared to wait for a response
before you go into exception handling. The user "dials" a specific
destination and, by whatever means, the device decides it's a
destination that requires location-based routing. You've included the
constraint that the device doesn't know the appropriate time to delay
the call setup for individual destinations. This means it has to apply a
common timeout. The timeout that you apply is going to be driven by the
boundary conditions you apply. Do you want the device to wait as long as
is reasonable because you *really* don't know how accurate the location
needs to be for any one of the possible destinations, or do you set a
lower value based on how long you think the user is really going to
wait? If you decide the former, then I would suggest that a minute is
enough time to expect an ultimate-accuracy answer. If you decide the
latter then I would suggest 10 seconds - though that will depend on what
sort of feedback the user has with respect to whether the device is in
an auto-locate procedure and that the call is pending. If there's
feedback then the implementer may decide this can be longer.

The other approach, as an implementer who goes to the trouble of
understanding the market, is to add some contextual knowledge about how
long networks typically do take to return location information and to
what accuracies. In addition, there'd be some research that correlates
this with the typical requirements of location-based call routing
demands. If you did that, you'd potentially come to the conclusion that
given that the technology deployed in public networks is driven by the
need to support emergency service with a fast-fix suitable for routing
available in under five seconds and, similarly, this is actually all
that any known location-based commercial call routing service needs. In
that case, I would expect the implementer to set the timeout to 6
seconds. Most calls, in practice, will get the location back in under a
second.

If you have a very specific need for highly accurate location in your
application, then the implementer needs to recognize that this could
take anything up to a minute - given the state of the art. I would
recommend that the implementer make sure that the necessary human
factors are included to provide the user with sufficient feedback as to
what is going on while that request is being processed. I would not
recommend that the implementer try to treat this application as if it
were one that *expects* location to be returned in two seconds.

At no time, as an implementer, would I consider it sensible to build my
application such that it waits forever. If the interface includes a
function for the user to intervene (cancel the location procedure) then
I'd set the timeout to something very large. Even then, based on the
state of the art for public networks, I'd probably set it to only five
minutes.

If I have a very specialist application in a completely proprietary
private network with an arcane location determination technology - for
example, my HELD client is a nano-bot measuring quantum fluctuations
over many hours, then I'd expect to apply my own domain knowledge to the
question of defining the timeout (maybe 365 days or until my research
budget expires).

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, 14 August 2007 3:17 AM
To: Dawson, Martin; 'GEOPRIV WG'
Subject: RE: [Geopriv] The "cold start" myth and the general solution

The PC has no idea how long to wait.  It doesn't know when an app will
actually need location.  It may be shortly after startup, it may be
minutes,
hours or days later.   It doesn't know (and doesn't care) if it's mobile
or
not.  It might be. 

The PC client is a good example because it's power profile is a lot
difference from a handset.  If it had a GPS, it would typically leave it
on,
even if no apps were using it.

The ONLY app that I know of that it sensitive to cold start is the
emergency
call case.  Most other apps tolerate start up fine, because the app just
waits for cold start to be over, and then runs.  Typical examples would
be a
navigation app.

Let's look at that.

Suppose you were writing code for a possibly mobile handset that
supported

What is the value, in seconds, that you recommend?  How did you come up
with
it?

Brian.

Hi all,

The "cold start" approach was cited as an exemplar scenario in a recent
post. This is where a computing device acquires its location once and
then
uses that for every location application until reboot or the device
changes
its network attachment.

It was Brian R who used the scenario - which is fine - but I'd also like
to
acknowledge that Brian is the source of the very good use case where the
device is attached to a LAN which is itself mobile. Brian talks about an
RV
driving down the interstate which has a LAN and which uses a wide area
wireless Internet access (e.g. 3G, WiMAX) from a public provider. The
mobile
WiFI access point that Avis now rents out is another example, and WiFi
LANs
are also available on train services in those places lucky enough to
have
such facilities (I'm confident it will become commonplace in the short
term).

A device using an Ethernet cable or WiFi network adaptor has no way of
knowing what the actual nature of the Internet connection is. It is
wrong
for a device which booted up and found itself attached to one these
layer
two services to *assume* that cold start was a valid approach. Yes, a
desktop PC with an appropriately knowledgeable user could be configured
to
correctly make this assumption. This relies on the device obtaining the
knowledge from an outside source (a user) but it's not inherently
readily
discoverable from the network.

User configuration implies a default configuration. What is the safest
default configuration for a HELD client? It is to assume that the device
*could* be mobile and that it is best to request location at the time
that
it is needed. As I'm sure everyone appreciates, it's common for
computers to
operate in perpetuity on the default settings and, even if they are
changed,
it is common for settings to not be adjusted when circumstances change.

Obtaining a cold-start location (or even periodically requesting a
refresh)
is not harmful in itself. Indeed, it is good to obtain and cache a "last
known" location so that a given application can decide for itself
whether it
is happy to use that if an immediately updated result isn't available.
However, even if it might not cause a problem in the 90% of DSL/cable
connected static devices, it is not a good general approach - and the
general approach of requesting location when it is needed covers the
static
situation anyway.

Cheers,
Martin

Martin Dawson

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]

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 13 Aug 2007 18:32:24 -0500

Brian,

Again this fundamentally misses the point about interactive
applications. They are built for users!

A great deal of time, effort and energy goes into developing
applications so that their responsiveness is palatable to users. You are
saying that this is not the case,  in which case Nintendo, Microsoft,
Sony and Sega should all stop research and testing in this area now
since you say it isn't required handwaving will do.

It has become evident that you are not interested in a use case, because
every use case that you suggest is simply dismissed as being
inappropriate. At this point I not going to try and provide you with
more use cases as I believe that your mind is set in the negative.

Those of us that have been working with location systems both in the
emergency and in the value-added space see a need for this parameter and
there is nothing you have stated thus far that has been convincing in
the least.  So much for speeding this along!

I propose the following to move things along:

1)       We keep the change in semantic that says no parameter as fast
as you can.

2)       We impose in the schema an upper limit on the responseTime
parameter, I am suggesting a minute.

Your applications may then choose not to use it.

Regards

James

Brian

----- Original Message -----
From: Dawson, Martin <[email-masked]>
To: Brian Rosen <[email-masked]>; GEOPRIV WG <[email-masked]>
Sent: Mon Aug 13 18:25:04 2007
Subject: RE: [Geopriv] The "cold start" myth and the general solution

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, 14 August 2007 3:17 AM
To: Dawson, Martin; 'GEOPRIV WG'
Subject: RE: [Geopriv] The "cold start" myth and the general solution

Let's look at that.

Brian.

Hi all,

Cheers,
Martin

Martin Dawson