RE: [Geopriv] Response time use cases (was: HELDcommentonresponseTimeparameter)

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Sat Aug 11 2007 - 01:39:35 EDT

So your implementation of this PC client would have it booting up, sending a single request, and then waiting forever for a response? That would be an extraordinarily bad implementation. If the request was lost for any reason, you'd have to reboot the PC before another one could be generated. And this particular niche use case is fine and dandy while the other four that have been described are not realistic? You've totally begged the question with the sly "..until some app needs it." Clause of the scenario. Then what? What does it do then and how long does it wait for the response? All you've done is punt the question of the actual application requirements by inserting a spurious "PC" agent in the middle of the request. As has also been pointed out more than several times now - in mobile access networks, location can only be meaningfully requested when it is needed. Your cold-start PC scenario simply isn't applicable in a mobile context. "It wants location now, or eventually." - By what authority is this premise justified? I know from personal experience that applications want location within a given period of time and, generally, want the best accuracy available in that time. They may state an accuracy requirement but, if that can't be met, they always want what could be determined anyway. My perspective is based on experience - whence the axiom you cite? Your premise also then, is that intermediate accuracy location technologies should never be developed and never be given access from clients? You're arguing that UTDOA, OTDOA, RTT, EOTD, subsector-TA, Radio-camera, and WiMAX scanning report integration are all invalid location technologies because they are slower than a cell-based location calculation but not as accurate as an arbitrarily protracted GPS calculation? It's an amazingly narrow-minded perspective of location technology. Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Saturday, 11 August 2007 12:56 PM To: Dawson, Martin; 'Henning Schulzrinne'; Stuard, Doug Cc: 'GEOPRIV WG' Subject: RE: [Geopriv] Response time use cases (was: HELDcommentonresponseTimeparameter) 1. A PC boots and wants location for any application that may need it. It has no time limit in mind. There is no sensible value for it to give. Nothing times out until some app needs it. When it asks for it, it has no idea if that is 20 seconds, 2 minutes, 20 minutes, 20 hours or 20 days. 2. Time to deliver, as has been pointed out several times, it mostly a cold start issue. After a short time, most systems deliver updates fairly rapidly. The fact that the device has 26 ways to calculate location does not mean the client cares. It wants location now, or eventually. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Friday, August 10, 2007 8:53 PM > To: Henning Schulzrinne; Stuard, Doug > Cc: GEOPRIV WG > Subject: RE: [Geopriv] Response time use cases (was: > HELDcommentonresponseTimeparameter) > > Hi Henning, > > You continue to repeat the same incorrect statements and not acknowledge > any of the valid points that have been made. Use cases have been > provided. What is the point of people providing use cases if you just > dismiss them without commentary as "not realistic"? > > Two questions you have not responded to and I insist you do > > 1. Please cite any real client-server request for location that would > not see the client imposing some time-out on the request. > > 2. Please explain how a LIS with 3 or more options for location > determination which trade off response time against accuracy could use > anything other than fast/bad or slow/accurate without this client > guidance. > > If all we can get is the same general unsupported and academic > statements made over and over again then this discussion is obviously > going nowhere. > > Brian, BTW, has agreed to the scalar parameter without acknowledging > himself to be a fan. I'd add the third question as to why you want to > prevent an, at worst, benign and always optional parameter if others > consider so strongly that it is valuable? > > Regards, > Martin > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, 11 August 2007 6:07 AM > To: Stuard, Doug > Cc: GEOPRIV WG > Subject: Re: [Geopriv] Response time use cases (was: > HELDcommentonresponseTime parameter) > > Currently, there is no way to specify the accuracy in the HELD > document, so I'm confused by your comment. As I've mentioned, I have > no objection to such an accuracy specification and have made an > accuracy suggestion earlier, although I agree with others that it has > its own set of issues. > > As I mentioned in that earlier post, only the accuracy requirement > matters. If I say "I need 100m accuracy for dispatch", I mean it - > and timing out earlier doesn't help me. (Subject to the 30s-style > system engineering restrictions that Brian has mentioned.) > > In all emergency calling cases, after all, I want data as quickly as > possible. If all I need is county-level accuracy for routing, I'm not > interested in waiting some additional seconds, since these seconds > just delay the response. If I was happy with a lower accuracy, I > would have specified it - and probably issued two queries, one low- > res to get the ambulance rolling in the right direction and one > "agap", to find the cubicle. > > If such a more elaborate accuracy specification turns out to be > useful, I think it should be pursued as a separate extension draft, > rather than having some half-baked solution that merely causes > complexity and interoperability problems. As an extension draft, it > can be appropriately scoped, labeled experimental as opposed to > standards track or whatever the working group considers most > appropriate. > > As Brian, Ted and I continue to point out, we cannot think of a > useful client time constraint that isn't completely arbitrary, beyond > the "asap" value. No real-life, verifiable example of an application > that has such time-only per-invocation constraints has been > identified. (We all agree that providers of location information will > likely be subject to upper-bound engineering constraints that they > have to satisfy in order not to get into trouble with regulators and > first responders.) > > Also, a remark on "average" patience: At least in phone services, > abandonment percentages tend to be exponentially distributed, i.e., > some people are very impatient, others wait forever. Thus, this tends > to be not terribly helpful even if it could be experimentally > determined. > > Henning > > On Aug 8, 2007, at 5:19 PM, Stuard, Doug wrote: > > > I think specifying some value of "when" is often more important than > > specifying some value of "good". > > > > > > Knowledge of the server's time-accuracy curve is IMHO irrelevant. > > It is > > what it is (or "are" where there are multiple location methods > > available). The client has his own time-accuracy tolerance curve > > based > > on his application, which should govern ("The customer is always > > right"). While accuracy is important, the key element is always time. > > The client request would, in effect say: "I would like 10 meter > > accuracy, and am prepared to wait up to a minute to get it. If not > > achieved by that time, give me the best you've got". (I haven't seen > > anyone say "I need x meters accuracy, and I am willing to wait however > > long it takes until that is achieved."...there's always a time limit, > > even if implicit). > > > > If the server can provide the requested 10 meter accuracy in 15 > > seconds, > > it's done. If not, it keeps working up to the one minute limit, then > > provides its "best effort" response (possible including its accuracy > > estimate). > > > > For an emergency request for routing purposes (i.e., a "quick > > fix"), the > > initial request would be something like: "I would like 500 meter or > > better accuracy, and am prepared to wait no more than 3 seconds to get > > it. If not achieved by that time, give me an 'unable to locate' or a > > 'use default routing' message". (Alternately, it could be of the form: > > "I need a location and associated accuracy estimate within 3 seconds > > with whatever accuracy you can provide. If not achieved by that time, > > give me an 'unable to locate' or a 'use default routing' message"). > > > > > > Doug > > > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Wednesday, August 08, 2007 1:55 PM > >> To: Dawson, Martin; Brian Rosen; Lisa Dusseault; Mary Barnes > >> Cc: geopriv@ietf.org; Henning Schulzrinne > >> Subject: RE: [Geopriv] Response time use cases (was: HELD > >> commentonresponseTime parameter) > >> > >> (snip) > >> > >> At one side, we have a willingness for two times: now and "when you > >> have > >> a good answer" (for some value of good). > > > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Tuesday, August 07, 2007 9:59 AM > >> To: Dawson, Martin > >> Cc: GEOPRIV > >> Subject: Re: [Geopriv] HELD comment on responseTime parameter > >> > >> As I believe Brian and I have explained, the client should be able to > >> request "asap" and "agap" ("as good as possible"). If I understood > >> Rohan correctly, he also alluded to a similar type of distinction in > >> the world of medical labs. > >> > >> As Brian noted, no useful location determination system has arbitrary > >> time constraints, measured in hours. As I've tried to explain, since > >> the client has no idea what the server's time-accuracy curve is, > >> providing a time parameter is meaningless to the client. > >> > > ---------------------------------------------------------------------- > > > -------------------------- > > 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 > > > > _______________________________________________ > 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] > > > > _______________________________________________ > 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 11 Aug 2007 00:39:35 -0500

This archive was generated by hypermail 2.1.8 : Sat Aug 11 2007 - 01:41:33 EDT