RE: [Geopriv] ResponseTime

From: Roger Marshall ^lt;RMarshall@telecomsys.com>
Date: Tue Aug 28 2007 - 15:10:41 EDT

Latency isn't always measured in the time it takes for a location server
to look up a row, but also, for example, for parlayed responses.
 
Some of the problems which exist today in the Wireless/CS space, not
accounted for here include:
 
-- "fast fix" vs. "normal fix", though the former could be construed as
a 'good enough' - even though it wouldn't always be the case (think
border conditions).
-- specification of different shape types with a 'given' confidence
(i.e., no input of client choice as to 67, 90, 95%, etc.)
 
A different approach is to return a set of coefficients to a
standardized formula (one already exists), with client input of
confidence level. This covers all rotational shape types. It doesn't
cover polygons.
 
-roger marshall.

________________________________

        From: Stuard, Doug [mailto:Doug.Stuard@andrew.com]
        Sent: Tuesday, August 28, 2007 11:59 AM
        To: Roger Marshall; Brian Rosen; peter_blatherwick@mitel.com;
Winterbottom, James
        Cc: GEOPRIV; Dawson, Martin
        Subject: RE: [Geopriv] ResponseTime
        
        

        What is the nature of the time/accuracy tradeoff for civic
location? In 2 seconds I can give you the state, in 10 the county and
in 30 the city?

         

        Doug

        From: Roger Marshall [mailto:RMarshall@telecomsys.com]
        Sent: Tuesday, August 28, 2007 2:50 PM
        To: Stuard, Doug; Brian Rosen; peter_blatherwick@mitel.com;
Winterbottom, James
        Cc: GEOPRIV; Dawson, Martin
        Subject: RE: [Geopriv] ResponseTime

         

        I agree with Peter's notion of a compromise, though I'd suggest
that for:

         

        -- civic location, only a single parameter is provided to denote
'asap' vs. 'agap within t seconds', as a value, and

        -- geo location, we punt for now and entertain more complex
solutions in the future, via extensions.

         

        -roger marshall

                 

________________________________

                From: Stuard, Doug [mailto:Doug.Stuard@andrew.com]
                Sent: Tuesday, August 28, 2007 11:29 AM
                To: Brian Rosen; peter_blatherwick@mitel.com;
Winterbottom, James
                Cc: GEOPRIV; Dawson, Martin
                Subject: RE: [Geopriv] ResponseTime

                See embedded comments.

                 

                Doug

                 

                From: Brian Rosen [mailto:br@brianrosen.net]
                Sent: Tuesday, August 28, 2007 1:49 PM
                To: Stuard, Doug; peter_blatherwick@mitel.com;
Winterbottom, James
                Cc: 'GEOPRIV'; Dawson, Martin
                Subject: RE: [Geopriv] ResponseTime

                 

                Generally, I think this is getting there. I think you
want a way for the server to tell the client what kinds of time/accuracy
tradeoffs it can make. Something simple would be fine. I just want to
see some way to represent the time/accuracy curve(s), recognizing that
they are non linear, discontinuous and not completely controlled. If
the server always gives you an answer within 100m in 30 seconds, no
matter what you ask for, I'd like the client to know that. I'm not
looking for the whole curve, just the shape and dimensions.

                 

                [Stuard, Doug] The fact that the time/accuracy tradeoff
is non-linear and often discontinuous is irrelevant, as it cannot be
known a priori by the client OR by the server (except in a general way).
IMO the actual shape of the curve matters little to the client. Time
and accuracy thresholds are the key items that matter. A
client/application should specify what it wants/needs, regardless of the
server's apparent intransigence. The client then must have a mechanism
for dealing with a response that is not entirely what it asked for
(don't we all?).

                 

                Recognize that you described this as all gated on time,
but you could have described it based on accuracy and come out the same;

                 

                [Stuard, Doug] Perhaps, but people are impatient, and
the concept of "good enough" is usually limited by "not soon enough"
(Case 5)

                 

                 there is a time/accuracy tradeoff, it's non-linear, and
you can hold one constant and vary the other.

                 

                [Stuard, Doug] This is in essence what you are doing
with Case 5 (time>0, no accuracy specified), and Case 2 (accuracy
specified, no time limit). You can do it either way.

                 

                Also need a mechanism to cope with time longer than a
few seconds.

                 

                [Stuard, Doug] Agreed

                 

                I agree that we need confidence. I dearly would love to
specify 90% and leave it at that. I fear we cannot. Normally, this is
something you get back from the server, not an input parameter.

                 

                [Stuard, Doug] I would think the client/application
would like to assume a "standard" (there's that word again!) value.
Perhaps this would be set at the server. We don't need to replicate the
current E9-1-1 confidence/uncertainty conundrum. People understand
uncertainty, but confidence is often lost on them. Better to settle on
a reasonably good but achievable confidence value (e.g., 90%, or
whatever makes sense for the application) then to leave it open.

                 

                Brian

                 

                 

________________________________

                From: Stuard, Doug [mailto:Doug.Stuard@andrew.com]
                Sent: Tuesday, August 28, 2007 1:20 PM
                To: peter_blatherwick@mitel.com; Winterbottom, James
                Cc: GEOPRIV; Dawson, Martin
                Subject: RE: [Geopriv] ResponseTime

                 

                Using only two optional parameters: (Time and
Accuracy), I think all request cases can be addressed, and fairly
simply:

                 

                1) No time or accuracy specified: "No location
required" (inclusion of either optional parameter would require a
location response).

                a. It was suggested that this case might mean
"AGAP, no time limit", but how is "AGAP" determined? - there has to be
some point at which calculations stop and a result is reported, either a
time limit or an accuracy threshold or convergence (cases 2 and 6
below))

                2) No time specified, accuracy specified: However
long it takes to achieve the specified accuracy.

                3) Time=0, no accuracy specified: ASAP with
whatever accuracy is available*

                4) Time=0, accuracy specified: ASAP so long as
specified accuracy met, otherwise fail.

                a. This case may be of limited usefulness.

                5) Time >0, no accuracy specified: AGAP within the
specified time limit*

                6) Time >0, accuracy specified: AGAP within the
time limit or until specified accuracy is achieved, whichever comes
first.

                 

                *In cases where there is no accuracy specification
(3&5), the accuracy should be included in the result if available. It
may be included in the others as well.

                 

                Most database based responses would either be of type 1
(civic) or type 3 (fixed geo).

                 

                Emergency call routing would be based on a Type 3
request or a Type 5 with an appropriate time limit

                 

                Also, the definition of "accuracy" needs to be
addressed. For calculated accuracy as in wireless, the uncertainty at a
specified confidence (90% is often mentioned) might be appropriate.

                 

                Doug

                 

                 

                From: peter_blatherwick@mitel.com
[mailto:peter_blatherwick@mitel.com]
                Sent: Tuesday, August 28, 2007 11:24 AM
                To: Winterbottom, James
                Cc: Stark, Barbara; Stuard, Doug; GEOPRIV; Dawson,
Martin; Robert Sparks; Roger Marshall
                Subject: RE: [Geopriv] ResponseTime

                 

                
                Hmmm .... This is tending towards more complicated, not
less. (Noting esp the proposal for possibly 3 parameters.)
                
                James wrote:
> Given my description of profiling above, would people
be prepared to accept the following:
>
> 1) No responseTime provided, you get AGAP, however
long that takes.
> 2) responseTime = 0, you get ASAP
> 3) responseTime >0, you get best in time provided.
>
> If people want other things, then they can profile
those in HELD extensions.
> This meets Peter's previous concern, if he wants
minimal wired-client support, his HELD client says responseTime=0.
                  
                Actually, in a wired case where location is actually
known virtually instantaneously, I would expect the client would include
no ReponseTime parameter at all.
                
                How about a different compromise? Since it *seems* to
be the case that ResponseTime is primarily a concern for mobile devices
(particularly cellular), how about it the parameter is an extension, but
mobile devices (or ones which might be mobile, such as soft clients), by
their nature, need to implement it. This is predicated on others in
cellular space also agreeing that ResponseTime is actually needed there.
(I am not a cellular expert, but also note most responses are coming
from what Robert rightly termed "just the folks that were active in the
discussion earlier" ;-)
                
                -- Peter

                 

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

         

        The information contained in this message may be privileged
and/or confidential. If you are not the intended recipient, or
responsible for delivering this message to the intended recipient, any
review, forwarding, dissemination, distribution or copying of this
communication or any attachment(s) is strictly prohibited. If you have
received this message in error, please so notify the sender immediately,
and delete it and all attachments from your computer and network.

         

------------------------------------------------------------------------
------------------------
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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 28 Aug 2007 12:10:41 -0700

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 15:12:36 EDT