RE: [Geopriv] ResponseTime

From: Stuard, Doug ^lt;Doug.Stuard@andrew.com>
Date: Tue Aug 28 2007 - 14:58:58 EDT

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 14:58:58 -0400

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 15:00:47 EDT