Re: [Geopriv] HELD comment on responseTime parameter

From: Shida Schubert ^lt;shida@ntt-at.com>
Date: Tue Jul 31 2007 - 16:48:19 EDT

 I read the HELD document to be a location configuration protocol which
is intended to
be used by the target of the location. In case of VoIP, it is generally
the device the caller
uses and not by the consumer of the location.

 What PSAP uses as a consumer of the location as I understand is not
HELD but rather
a dereference protocol currently discussed as an individual draft.

 If I understand you correctly, you are saying that HELD doesn't need a
responseTime
but ability to indicate responseTime is necessary for PSAP in
dereference protocol.

 Regards
  Shida

Stuard, Doug wrote:
> For commercial applications, I don't disagree, as the client (user)
>
> generally has little idea about what a reasonable cut off (i.e., the "I
>
> give up") time is for a given request, or what the trade-offs are.
>
> That's like trying to decide if you should take one more pull on the
>
> slots in Vegas.
>
>
>
> For emergency service applications however, the client ultimately is the
>
> PSAP which IS knowledgeable about what a reasonable threshold is (the
>
> famous 30 second window) and the accuracy that can be expected within
>
> that threshold (This is where the "experience has shown" factor comes
>
> in). In addition, if the threshold time is exceeded, a re-bid can
>
> effectively extend it if needed (and need is frequently situational and
>
> not automatic). (Well, maybe - currently a re-bid re-starts the location
>
> process rather than extending it. Probably reasonable for tracking
>
> moving targets - see below).
>
>
>
> "As soon as possible" thus translates to "quick and accurate enough for
>
> proper call routing", while "As accurate as possible" translates to
>
> "accurate enough for dispatch purposes - up to a point". Waiting
>
> another 2 minutes to decrease uncertainty from 150 meters to 10 meters
>
> is past the point of diminishing returns, in my view.
>
>
>
> While a client may specify "zero" at one end of the spectrum (and
>
> actually get something in the order of seconds - certainly "pretty
>
> quick" in human terms), I disagree that from a practical standpoint
>
> "infinity" is the other end (whether in geological or human terms).
>
> That would be the equivalent of "I'll call you back sometime". The
>
> outside limit is of course situational, ranging from 30 seconds for
>
> emergency services to perhaps 2 or 3 minutes (and certainly within the
>
> length of the typical telephone call) for commercial applications ("All
>
> agents are busy helping other customers. Your expected wait time
>
> is...").
>
>
>
> None of this applies to determining civic location, of course (it is
>
> what it is), provided that validation, routing and display can be
>
> provided for timely emergency dispatch.
>
>
>
> Doug
>
>
>
>
>
>
>> -----Original Message-----
>>
>
>
>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>>
>
>
>> Sent: Monday, July 30, 2007 1:14 PM
>>
>
>
>> To: Dawson, Martin
>>
>
>
>> Cc: geopriv@ietf.org
>>
>
>
>> Subject: Re: [Geopriv] HELD comment on responseTime parameter
>>
>
>
>
>
>> I think the basic disconnect is that I'm assuming that we should
>>
>
> design
>
>
>> the protocol to be most useful to the client and that I cannot imagine
>>
>
>
>> how a client can usefully pick a time value beyond "immediately"
>>
>
>
>> (meaning within the 1-2 second post-dial delay margin available during
>>
>
>
>> a
>>
>
>
>> call setup) or "whenever" (within a reasonable time of, say, a minute
>>
>
>
>> or
>>
>
>
>> two). I know no client application that somehow can wait 10 seconds,
>>
>
>
>> but
>>
>
>
>> not 11 seconds, particularly if the answer it can get in 10 seconds is
>>
>
>
>> useless for its application. In that case, it has just "wasted" 10
>>
>
>
>> seconds and has to guess whether trying again with 11 or 15 or 20
>>
>
>
>> seconds will yield any improvement or whether this is pointless.
>>
>
>
>
>
>> Post-dial applications need answers immediately, and dispatch
>>
>
>
>> applications probably want updates, so that they can provide better
>>
>
>
>> estimates after they have started the dispatch process. (However, for
>>
>
>
>> dispatch, I'm having a hard time envisioning that this really matters.
>>
>
>
>> The realistic time frame to determine the nature of the emergency is
>>
>
>
>> probably on the same order, a few minutes, as the maximum probable
>>
>
>
>> location determination time, unless we're talking about asking the
>>
>
>
>> caller to get out their chronometer and sextant.)
>>
>
>
>
>
>> The pre-call case also has no natural time limit, beyond "as
>>
>
> accurately
>
>
>> as possible".
>>
>
>
>
>
>> Since a client has no clue what the time-resolution function is, it
>>
>
>
>> essentially has to pick an arbitrary time value. It has no idea
>>
>
> whether
>
>
>> there are steps in that time-resolution function, so that waiting a
>>
>
>
>> second longer gets much better accuracy. It has no idea whether asking
>>
>
>
>> again with a slightly longer interval will improve the result.
>>
>
>
>
>
>> I generally find "experience has shown" arguments of the
>>
>
>
>> argument-by-authority kind and thus not particularly helpful. We know
>>
>
>
>> that there are several discrete location resolutions that are useful,
>>
>
>
>> namely the "sufficient to do LoST routing" and "sufficient to do
>>
>
>
>> dispatch". A client doesn't need exactly N meters of accuracy.
>>
>
>
>
>
>> The likely outcome will be that clients will specify 0 and some
>>
>
>
>> approximation of infinity as values, with the danger that requests
>>
>
> will
>
>
>> fail if 0 is taken as something other than "whatever you can do
>>
>
>
>> immediately". Or client implementors will "learn" that specifying 5
>>
>
>
>> seconds will get reasonable results most of the time in the network
>>
>
>
>> they
>>
>
>
>> tested with. None of this is useful.
>>
>
>
>
>
>> I don't know of any incremental-resolution technique for civic
>>
>
>
>> locations, so I suspect it's more productive to focus on geo to keep
>>
>
>
>> the
>>
>
>
>> problem manageable.
>>
>
>
>
>
>> The basic model for protocol design is not to have to prove why
>>
>
>
>> something is NOT useful, but that a particular mechanism is the least
>>
>
>
>> complicated and most appropriate solution for a clearly stated
>>
>
>
>> requirement. I know of no requirement that says that a client has a
>>
>
>
>> specific time limit beyond the "immediate" value; we do know that
>>
>
>
>> clients have different rough accuracy requirements.
>>
>
>
>
>
>> Henning
>>
>
>
>
>
>> Dawson, Martin wrote:
>>
>
>
>>> I think the point is still being missed - and the assumption seems
>>>
>
> to
>
>
>> be
>>
>
>
>>> that this is a client-focussed parameter. It is not the client that
>>>
>
>
>>> makes use of this information; it is the server. Particularly in
>>>
>
>
>>> wireless access networks where a location server may have multiple
>>>
>
>
>>> technologies available to it, there is a general need to trade off
>>>
>
>
>>> response time and accuracy. Accept that there are "n" techniques and
>>>
>
>
>>> that "n" can be more than two. The parameter allows the server to
>>>
>
>
>>> provide an optimal accuracy in response to a location request by
>>>
>
>
>> giving
>>
>
>
>>> it an understanding of how long the client is prepared to wait.
>>>
>
>
>
>
>>> It's no good assuming that a response now with some (asynchronous?)
>>>
>
>
>>> update later is adequate. In scenarios where a device wants a
>>>
>
>
>> location
>>
>
>
>>> value so it can send it to an application for immediate processing
>>>
>
> by
>
>
>>> that application, there is no use for "subsequent" values. That's
>>>
>
> why
>
>
>>> I'm puzzled by the request for "use cases" for this parameter - it's
>>>
>
>
>>> applicable to every use case for location requests. The location
>>>
>
>
>> server
>>
>
>
>>> can't assume anything about what is going to be useful to the client
>>>
>
>
>>> "later".
>>>
>
>
>
>
>>> Not having a scalar response time criterion means that the server
>>>
>
> can
>
>
>>> never optimize the accuracy using the most suitable available
>>>
>
>
>>> technologies. How does anyone propose that a HELD server select the
>>>
>
>
>>> optimal positioning technology for a one-off request without some
>>>
>
>
>>> understanding of how long the client is prepared to wait?
>>>
>
>
>
>
>>> Experience has shown that an accuracy requirement parameter is not
>>>
>
> so
>
>
>>> useful. Applications generally want the most accurate location they
>>>
>
>
>> can
>>
>
>
>>> get within the timeframe that they are prepared to wait. The
>>>
>
> accuracy
>
>
>> is
>>
>
>
>>> actually part of the result - embodied in the provided uncertainty
>>>
>
>
>>> information. There's no guarantee about how accurately an arbitrary
>>>
>
>
>>> server can locate a target. Also, when it comes to civic location,
>>>
>
>
>>> there's a semantic mismatch with respect to scalar accuracy.
>>>
>
>
>
>
>>> Cheers,
>>>
>
>
>>> Martin
>>>
>
>
>
>
>
>
>
>
>> _______________________________________________
>>
>
>
>> 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
Received on Tue, 31 Jul 2007 13:48:19 -0700

This archive was generated by hypermail 2.1.8 : Tue Jul 31 2007 - 16:49:04 EDT