RE: [Geopriv] ResponseTime

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Tue Aug 28 2007 - 15:45:19 EDT

James pointed out to be that PIDF-LO profile actually does say use 67%.
While I'd much prefer 90 or 95%, a single standardized value beats any set
of values hands down.

 

Brian

 

  _____

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, August 28, 2007 3:05 PM
To: 'Stuard, Doug'; peter_blatherwick@mitel.com; 'Winterbottom, James'
Cc: 'GEOPRIV'; 'Dawson, Martin'
Subject: RE: [Geopriv] ResponseTime

 

In line

 

  _____

From: Stuard, Doug [mailto:Doug.Stuard@andrew.com]
Sent: Tuesday, August 28, 2007 2:29 PM
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?).

<br>The server knows what the curves look like. It's not precise (this
much accuracy in this much time), but they know the shape. I believe in
apps that adapt to reality, rather than assuming the server can always do
what the client wants. The client wants infinite accuracy in zero time. It
will put up with less, but it wants to know what it has to work with. This
is a big stumbling block: you-all seem to think it's way too complicated for
a poor little app to understand, so give big daddy server your absolute drop
dead limits and big daddy will do the best it can. I don't believe in big
daddy. My apps can make use of whatever information you can give me. You
all think there are finite limits that apps drop dead after. There aren't;
all the numbers are arbitrary, and without any information they are really
arbitrary.

 

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.

 

<br>Hey, I like it; if you can get everyone to agree, 90% is a good number!

 

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]

 

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 28 Aug 2007 15:45:19 -0400

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