RE: [Geopriv] ResponseTime

From: Roger Marshall ^lt;RMarshall@telecomsys.com>
Date: Mon Aug 27 2007 - 17:21:28 EDT

What about using two independents, or even three variables?
 
Timing and Uncertainty are two variables that could, (if implemented
rightly among the elements which determine location), provide additional
control, as well as allow the server to choose among different back-end
determination technologies, as Robert mentioned in this thread.
 
Examples of:
0 : 0 (means give me whatever location you have asap)
0 : 50 (means provide location which is reported as being within a
radius of 50m asap)
30 : 50 (means provide a location inside a radius of 50m within 60
seconds)
 
Coupling what is also done (by some vendors) within Wireless/CS domains
today, you could add a third variable, though a 'confidence' parameter
is still somewhat misunderstood (and certainly mis-applied), so most
might want to set this third value to a constant for now:
 
30 : 50 : 95 (give me the location with a 50m or less tolerance,
determined within 30 seconds with a confidence of at least 95%)
 
-roger marshall.

________________________________

        From: Stuard, Doug [mailto:Doug.Stuard@andrew.com]
        Sent: Monday, August 27, 2007 2:13 PM
        To: Dawson, Martin; Stark, Barbara; peter_blatherwick@mitel.com;
Robert Sparks
        Cc: GEOPRIV
        Subject: RE: [Geopriv] ResponseTime
        
        

        Given the practical limits stated, option i) is good

        Option ii) as stated seems too open ended. If restated to "as
accurate as you can get it within the stated time limit", I think
virtually all realistic use cases are covered.

         

        In practice, a number of techniques converge within 20 seconds
or so, so you could either wait until the stated time limit, or until
(reasonable) convergence is achieved.

         

        Doug

         

         

        From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
        Sent: Monday, August 27, 2007 4:46 PM
        To: Stark, Barbara; peter_blatherwick@mitel.com; Robert Sparks
        Cc: GEOPRIV
        Subject: RE: [Geopriv] ResponseTime

         

        The semantics of response time are "most accurate you can get
within this time".

         

        I think I've seen both defaults proposed. That is, the absence
of the response time parameter can be:

         

        i) As fast as possible at whatever accuracy that
results in.

        ii) Take as long as you like until you think it's as
accurate as you can get it.

         

        Given there are technologies that could see incremental (and
diminishingly small) improvements in accuracy for every
iteration/measurement - even if it went on all day - the LIS would have
to apply its own interpretation of "accurate as you can get it" but
that's an invisible judgement as far as the client is concerned.

         

        Obviously both defaults can't apply. To me, logically, a
response time of zero would mean as fast as possible (since zero can
only have theoretical significance so it might as well have a special
interpretation). That would leave option ii) as the default semantic.

         

        Cheers,

        Martin

         

________________________________

        From: Stark, Barbara [mailto:bs7652@att.com]
        Sent: Tuesday, 28 August 2007 6:30 AM
        To: peter_blatherwick@mitel.com; Robert Sparks
        Cc: GEOPRIV
        Subject: RE: [Geopriv] ResponseTime

         

        I think there is a need for a device to be able to ask for a
"ASAP" vs. "accurate" response for location to be used when requesting
emergency services. If it were totally optional, and not using it means
"ASAP", then how does a device request "accurate"? I was suggesting
using a default value, like 60 seconds (but hopefully recommended by
phonebcp) to mean "accurate".

        Barbara

         

________________________________

        From: peter_blatherwick@mitel.com
[mailto:peter_blatherwick@mitel.com]
        Sent: Monday, August 27, 2007 2:39 PM
        To: Robert Sparks
        Cc: GEOPRIV
        Subject: Re: [Geopriv] ResponseTime

        
        Hi,
        
> ... need to hear from more of the group than
> just the folks that were active in the discussion earlier in
the month
        
        I have stayed mostly out of the debate thus far, so here goes.

        
        I would support response time parameter ONLY as an optional
extension. This for the following reasons:
        
        o I do not see value in it for the most part; I expect most
applications (including ECS) simply don't need it or it would bring
fairly minimal value added. (I can certainly see some special cases /
applications where it might be helpful, hence do see value as optional
extension for those.)
        
        o It seems very difficult to make such a parameter specific
enough to get the proposed value out of it in any consistent way,
        
        o MOST IMPORTANT I desperately want endpoints needing to support
HELD for ECS purposes to have an absolutely ruthlessly simple subset of
the functionality that they must implement. The subset must be both
small (footprint) and very easy to implement correctly. Endpoints that
want to do more than ECS can add to the simple subset by using extended
options, but those that do only the ECS part need to be very
constrained. The value added bar needs to be set very high for the core
subset. The value of response time parameter in ECS does not make that
grade for me.
        
        Just to be clear on that last point, I'm not all that concerned
about the protocol itself (pretty easy) but more so about the
implications to the rest of the implementation: What to do if response
does not come back in requested time ... what to do if not at requested
accuracy .. what if .. what if .... And also I have the general concern
of "feature creep", of which this is one potential example.
        
        -- Peter
        .
        
        
        

 

Robert Sparks <rjsparks@nostrum.com>

27.08.07 12:05

        
        To: GEOPRIV <geopriv@ietf.org>
        cc:
        Subject: [Geopriv] ResponseTime

        
        
        
        All -
        
        Lets push to close on the responseTime question.
        
        To do this, I'm going to need to hear from more of the group
than
        just the folks that were active in the discussion earlier in the
month.
        
        So far, I've seen a good argument that a server can have
different
        technologies available for determining location and would
benefit
        from knowing something about how long a client is willing to
wait in
        order to choose which one to focus on. There has been a question

        about an implicit time/accuracy tradeoff here and a suggestion
that
        we should explore a more explicit separation of indicating those
things.
        
        I've also seen a good argument that it is unclear how a client
        implementation is going to provide values that would be useful
to the
        server. Without more clarity around this point, I see discomfort
from
        several people that the proposed mechanism is an opportunity for

        "Unintended Consequences" to rear its head.
        
        On rereading the threads, I strongly suspect that there are a
set of
        assumptions going into arguing for this parameter that haven't
been
        made explicit yet, and I'd like to try a round of teasing those
out
        to see if it closes the gap in the discussion.
        
        Lets start with these two statements (which I _think_ the folks

        pushing for the parameter are assuming are true - correct what I
have
        wrong please):
        
        1) The clients will provide a useful indication of responseTime
from
        the server's point of view.
        2) Different clients (or different applications at the same
client)
        will provide different enough values to make the same server
choose
        different location technologies in servicing the query.
        
        I can see the parameter helping a system work as long as the
service
        has some way to tell the client what to ask for (and I recognize
that
        means the client has to know what service it's invoking).
        
        James (or anyone else who has deployed or is developing a
deployment
        of something like this) - do you expect to have some influence
in a
        deployment over what the clients include in this parameter? Are
you
        expecting to have a relationship with the vendors providing
clients
        that lets you hand them values to hardcode,
        or give you a configuration interface you can use as a service
        provider? Or are you expecting that to be entirely outside your
control?
        
        RjS
        
        
        
        
        _______________________________________________
        Geopriv mailing list
        Geopriv@ietf.org
        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]

        *****

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

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 27 Aug 2007 14:21:28 -0700

This archive was generated by hypermail 2.1.8 : Mon Aug 27 2007 - 17:23:56 EDT