RE: [Geopriv] ResponseTime

From: Roger Marshall ^lt;RMarshall@telecomsys.com>
Date: Tue Aug 28 2007 - 17:38:49 EDT

Hey there Martin:
There is such a system in use today, and what I can do is offer to
provide a more detailed explanation in text of how this works, which
would provide a better basis for discussion.
 
-roger marshall.

________________________________

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

        Hi Roger,

         

        Can you provide an example of a real system that generates these
7 coefficients? That is, what is being measured and how does this
resolve into the discrete coefficients and what are the significance of
these coefficients?

         

        I'm trying to understand where you're coming from but it's a
little too cryptic for me at the moment.

         

        Cheers,

        Martin

         

        
________________________________

        From: Roger Marshall [mailto:RMarshall@telecomsys.com]
        Sent: Wednesday, 29 August 2007 6:51 AM
        To: Brian Rosen; Stuard, Doug; peter_blatherwick@mitel.com;
Winterbottom, James
        Cc: GEOPRIV; Dawson, Martin
        Subject: RE: [Geopriv] ResponseTime

         

        One way to reduce complexity (may not sound like it at first) is
to:

         

        -- program: one standardized function (produces 7 coefficients
from a couple of inputs) to describe any common shape

        -- input: a combination of confidence, uncertainty (max), and
timing (max) as input variables

        -- output: the 7 coefficients, plug them in and present the
location/shape

         

        The client gets to control everything through input variables,
whether it's an end device, middlebox, or PSAP client.

        One client (e.g., the end-device) can use a low time, a low
confidence to get routing information, gets the coefficients - and the
PSAP client reuses the conveyed coeff's along with their 'standard' 95%
confidence input value.

         

        -roger marshall.

                 

                
________________________________

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

                Okay, but what are you proposing?

                 

                Having a standardized value is so much more useful than
the absolute number. Generally, every user I ever talked to was unable
to use confidence unless all sources gave them the same confidence. If
they varied, then they were forced to ignore it; nothing they could
think of doing: displaying, calculating, dispatching, routing... could
change based on the value of confidence.

                 

                If you have the same value, then at least you can
compare two locations from different sources and they mean the same
thing. You still can't use confidence for displaying, calculating,
dispatching or routing.

                 

                
________________________________

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

                 

                This gets to the nagging problem of how good is 'good
enough'? Determining elements can certainly provide position, based on
input of 67% confidence, but they can also do better. If you're willing
to wait a few more seconds, they can churn out a more accurate result
based on a 90 or 95% input value. In fact, maybe they'll have to use
95% to get the level of precision that some regulatory agency will ask
for someday. By providing confidence value as an input to these
mechanisms, you can achieve location hiding (to some degree) as well.

                 

                -roger marshall.

                         

                        
________________________________

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

                        James pointed out to be that PIDF-LO profile
actually does say use 67%. While I'd much prefer 90 or 95%, a single
standardized value beats any set of values hands down.

                         

                        Brian

                         

                        
________________________________

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

                         

                        In line

                         

                        
________________________________

                        From: Stuard, Doug
[mailto:Doug.Stuard@andrew.com]
                        Sent: Tuesday, August 28, 2007 2:29 PM
                        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?).

                        <br>The server knows what the curves look like.
It's not precise (this much accuracy in this much time), but they know
the shape. I believe in apps that adapt to reality, rather than
assuming the server can always do what the client wants. The client
wants infinite accuracy in zero time. It will put up with less, but it
wants to know what it has to work with. This is a big stumbling block:
you-all seem to think it's way too complicated for a poor little app to
understand, so give big daddy server your absolute drop dead limits and
big daddy will do the best it can. I don't believe in big daddy. My
apps can make use of whatever information you can give me. You all
think there are finite limits that apps drop dead after. There aren't;
all the numbers are arbitrary, and without any information they are
really arbitrary.

                         

                        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.

                         

                        <br>Hey, I like it; if you can get everyone to
agree, 90% is a good number!

                         

                        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 14:38:49 -0700

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 17:45:06 EDT