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

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

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] <mailto:[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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: [email-masked]
Date: Mon, 13 Aug 2007 16:00:26 -0400

Hi Martin, list, 

The mobile network (a la NEMO) is an interesting example. Just a quick 
point or two to throw on the fire.   I may be missing some context here, 
since not sure what the original thread was (response time use cases?) but 
here goes anyway. 

> ... 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. 
> ... not a good general approach – and the general approach of 
> requesting location when it is needed covers the static situation 
> anyway.

I just wanted to point out the obvious.  Request/response is not the only 
way to achieve the goal of being up to date.  Auto-updating, from the 
network infrastructure towards the device is also quite feasible, and so 
would be some form of subscription approach.  For example, in the former, 
LLDP-MED would naturally have this effect, since if location changed by 
more than some threshold amount, the corresponding location MIB would 
change, and an updating advertisement would be sent as a result. 

(Oh, and I *do* agree that *one-time* cold start approach is not the right 
general solution BTW, for the reasons already cited.) 

> ... A device using an Ethernet cable or WiFi network adaptor has 
> no way of knowing what the actual nature of the Internet connection 
> is ...

But then, if it is getting auto-updates from the network or via 
subscription anyway (as above), it does not need to know this either. 

Also, we need to wonder what "up to date" means in these contexts.  Even 
if the location is determined within ms of placing the emergency call, if 
the device is attached to a NEMO network on a high speed bullet train 
travelling at 200+ kmh, that location is again invalid almost instantly. 

(Here, a variant on Marc's relative location idea might be handy ... "i am 
located 55m from front of the speeding bullet train number 666  ...   ;^) 

- peter

"Dawson, Martin" <[email-masked]>
11.08.07 21:37
 
        To:     "GEOPRIV WG" <[email-masked]>
        cc: 
        Subject:        [Geopriv] The "cold start" myth and the general 
solution

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 13 Aug 2007 17:35:16 -0500

Hi Peter,

You're quite correct that this is another approach to dealing with
location in a mobile environment.

In 3GPP, this mode is called "deferred" and this mode is split into
"periodic" and "notification". Periodic is what it sounds like - a
location update is provided regularly with a nominated reporting period.
Notification means that an update is sent when some prescribed event
occurs (e.g. UE available). A notification based on moving a certain
distance is a form of the latter. Hasn't Rohan (or somebody) done work
on defining semantics for a service such as this?

I wrote my text, I admit, with the presumption of HELD as the location
service protocol. Being request/response, it doesn't presume to offer
this facility.

In practice, nobody has implemented the deferred service in cellular.
The combination of the fact that location determination consumes network
resources (so effectively monitoring devices continuously is expensive)
and the lack of imperative (so far) in the application space means that
it hasn't reached activation energy yet. The Internet environment will
likely offer more impetus for this sort of service (I'm speculating) -
and I certainly have no objection to a protocol being ratified to
support it.

Cheers,

Martin

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 14 August 2007 6:00 AM
To: Dawson, Martin
Cc: GEOPRIV WG
Subject: Re: [Geopriv] The "cold start" myth and the general solution

Hi Martin, list,   

The mobile network (a la NEMO) is an interesting example. Just a quick
point or two to throw on the fire.   I may be missing some context here,
since not sure what the original thread was (response time use cases?)
but here goes anyway.   

> ... it is good to obtain and cache a "last known" location so that 
> use that if an immediately updated result isn't available.   
> ... not a good general approach - and the general approach of 

I just wanted to point out the obvious.  Request/response is not the
only way to achieve the goal of being up to date.  Auto-updating, from
the network infrastructure towards the device is also quite feasible,
and so would be some form of subscription approach.  For example, in the
former, LLDP-MED would naturally have this effect, since if location
changed by more than some threshold amount, the corresponding location
MIB would change, and an updating advertisement would be sent as a
result.     

(Oh, and I *do* agree that *one-time* cold start approach is not the
right general solution BTW, for the reasons already cited.)   

Also, we need to wonder what "up to date" means in these contexts.  Even
if the location is determined within ms of placing the emergency call,
if the device is attached to a NEMO network on a high speed bullet train
travelling at 200+ kmh, that location is again invalid almost instantly.

(Here, a variant on Marc's relative location idea might be handy ... "i
am located 55m from front of the speeding bullet train number 666  ...
;^)   

- peter 

11.08.07 21:37 

Hi all, 

  

  
  
Cheers, 
Martin 
  
Martin Dawson 

 

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