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

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Sat Aug 11 2007 - 00:31:56 EDT

Brian, As I have responded to this scenario several time now, and from experience in deploying these systems your summary is na´ve and incorrect. The application space where things will care about exactly this scenario is not the PC sitting on a desktop plugged into a DSL or cable line. It is a wireless solutions space, be that cellular, wiMAX or community WiFI. It is the situation where you have an application that needs location and then needs to do something with it, the subscribe notify doesn't matter, because without location the application fails. Not getting a response within 6 to 8 seconds results in such a degraded user experience that the application is no viable. Simply because you can't imagine such applications existing doesn't reduce their viability or peoples want for them. The emergency case that you and several other keep suggesting as gimme the fastest you can, isn't true either, at least in the cellular space today it isn't. The cell-based routing that is often talked about here, is quoted in NENA and other circles as having 30% misroutes in the United States, and lead to enhancements in J-STD-036B to support fast-fix solutions for routing. Removing the repsonseTime parameter will result in this type of location fix not being available, as it clearly falls into the grey category between fast as you can, and as good as possible. Please don't try and tell me that this isn't a valid use-case because it is deployed today! I have now described several VALID use cases where this parameter will be useful, none of the arguments presented against the inclusion of this parameter have indicated how this parameter is harmful and this is especially true with the agreed change in semantics. Regards James > -----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 > > > > _______________________________________________ > 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 Fri, 10 Aug 2007 23:31:56 -0500

This archive was generated by hypermail 2.1.8 : Sat Aug 11 2007 - 00:33:57 EDT