Re: [Geopriv] HELD comment on responseTime parameter

From: Richard Barnes ^lt;richard.barnes@gmail.com>
Date: Mon Jul 23 2007 - 15:03:15 EDT

Maybe the disconnect is this: In other protocols, time-outs are fixed
in the standard, not set differently from one transaction to another.
For instance, RFC 3261 sets a whole host of timers to default values,
and says, essentially, "Don't deviate from these defaults unless you
have a really good reason." I think that HTTP sets similar
time-outs.

The question is, why should HELD behave differently?

--Richard

On 7/23/07, Winterbottom, James <James.Winterbottom@andrew.com> wrote:
> Brian,
>
> You have repeatedly stated an arbitrary 30 second I will give up time.
> I can see applications saying 20 second best you can give please.
> Having the scalar allows you to still achieve what you want, it provides
> flexibility for other applications developed by people with far more
> imagine than you or I.
>
> If the LIS/LCS knows when the client is likely to give up, then it has
> the opportunity to forestall that and fallback. Without it the query
> simply fails.
>
> Cheers
> James
>
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Tuesday, 24 July 2007 4:51 AM
> > To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes'; geopriv@ietf.org
> > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> >
> > I don't wish to be obstinate, or obstructionist.
> >
> > I'm simply asking for a use case. I can't think of one.
> >
> > I get the notion that if you force the issue, the client eventually
> wants
> > to
> > give up and get the best location it can. I think it has GREAT
> difficulty
> > in coming up with a numeric limit which has time frames measured in
> > seconds.
> > I don't know how a client would do that.
> >
> > I think the best way forward is to cut, not expand complexity.
> >
> > Request timeouts are short in code; a point you wish to ignore. They
> are
> > much shorter than 30 seconds. Most are shorter than a second. When
> you
> > need to wait longer than that, you need to do something complex, like
> > create
> > a polling loop, or spin off a thread or something. I know how to
> write
> > this
> > kind of code. Code doesn't block for 30 seconds.
> >
> > I don't want a protocol that takes 30 seconds to complete single
> > request/response cycle. I don't think code is written that way. I
> want
> > an
> > event or call back mechanism for that. If all I got was effectively,
> > "now",
> > that is enough. We need a mechanism that does event notification or
> call
> > back for updates. Use that if "now" won't work. In nearly every real
> > system, "now" always works; it's just that the location information
> may be
> > rough (like cell site/sector), the first time you request it.
> >
> > I think we have two mechanisms: an LCP and a dereference mechanism.
> The
> > dereference mechanism needs a notification or call back. That is
> > sufficient. I'd like to stop there, rather than have a value
> mechanism
> > with
> > a call back or event other than dereference.
> >
> > I propose to eliminate the parameter entirely. You get an "immediate"
> > response, a value or a reference.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > Sent: Monday, July 23, 2007 2:09 AM
> > > To: Brian Rosen; Stark, Barbara; Mary Barnes; geopriv@ietf.org
> > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > >
> > > Well, that's rubbish. If a VoIP phone sends a request for location,
> are
> > > you suggesting it will be prepared to wait forever before attempting
> to
> > > make the call anyway or cancelling the operation or whatever?
> Perhaps
> > > you've never written client code. It just needs to provide the same,
> or
> > > lower, time to the location server as the one associated with its
> > > request timeout.
> > >
> > > In any case, there's another approach that will give you your
> desired
> > > semantics and still maintain what I consider to be the essential
> scalar
> > > parameter.
> > >
> > > A response value of zero is essentially meaningless - no result can
> be
> > > returned in zero time. So, how about the value of zero be given
> special
> > > semantics. This would be your "right away" semantics - that is, the
> > > location server will return the fastest (and possibly least
> accurate)
> > > location that it can muster and return that - however long it takes.
> > >
> > > How to deal with your other semantic "take as long as you like but
> get
> > > me the best, most accurate, location that you can muster" is a bit
> > > different.
> > >
> > > It's hard to see how to explicitly indicate that but, if the
> response
> > > time parameter is made optional, then it could be the default
> semantic
> > > in the case of the response time not being provided.
> > >
> > > How does that sound as a compromise?
> > >
> > > Cheers,
> > > Martin
> > >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Monday, 23 July 2007 10:18 AM
> > > To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes';
> geopriv@ietf.org
> > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > >
> > > No, I want a use case: some application where the client has some
> notion
> > > of
> > > how long it can wait expressed in some kind of scalar.
> > >
> > > I can't think of an application where the client has some threshold
> of
> > > waiting which it has regardless of what the server can do, and it
> can
> > > usefully construct a value to put in a scalar.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > Sent: Sunday, July 22, 2007 6:35 PM
> > > > To: Brian Rosen; Stark, Barbara; Mary Barnes; geopriv@ietf.org
> > > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > > >
> > > > Client advises server that it can wait 5 seconds for a response to
> be
> > > > used in a routing application. Server invokes first higher level
> of
> > > > accuracy calculation (rather than fastest / least accurate).
> Client
> > > > receives more accurate location [than if it had asked for an
> immediate
> > > > response]. Routing application receives a more accurate location
> than
> > > it
> > > > may have otherwise. Routing accuracy for the application is
> therefore
> > > > improved.
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Monday, 23 July 2007 6:54 AM
> > > > To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes';
> geopriv@ietf.org
> > > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > > >
> > > > Please supply a use case for an L7 Location Configuration Protocol
> > > that
> > > > can
> > > > profitably use a scalar.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > > Sent: Sunday, July 22, 2007 2:13 AM
> > > > > To: Brian Rosen; Stark, Barbara; Mary Barnes; geopriv@ietf.org
> > > > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > > > >
> > > > > All the client has to know is how long it is prepared to wait
> for a
> > > > > result. That's it.
> > > > >
> > > > > I don't see any new information in your post - a couple of
> things I
> > > > > disagree with but none that are really relevant to how the delay
> > > > > tolerance should be prescribed. I vote for a scalar parameter.
> > > > >
> > > > > Cheers,
> > > > > Martin
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > > Sent: Sunday, 22 July 2007 6:27 AM
> > > > > To: Dawson, Martin; 'Stark, Barbara'; 'Mary Barnes';
> > > geopriv@ietf.org
> > > > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > > > >
> > > > > I'm sorry, but this still makes no sense to me.
> > > > >
> > > > > I'm having difficulty figuring out how any application can use
> any
> > > > > values
> > > > > other than "now" and "when it's good", especially with no
> accuracy
> > > > > parameters. Whether "when it's good" is 5 seconds, 15 seconds,
> 30
> > > > > seconds
> > > > > or any other value, I still don't see how you can really use it.
> > > > >
> > > > > I understand that the methods for measurement are varied, and
> have
> > > > > different
> > > > > response times. I don't see how a client of the protocol can
> make
> > > use
> > > > > of
> > > > > that acknowledged fact. All of the apps that use location that
> I
> > > can
> > > > > think
> > > > > of only can use "now" or "when it's good", as long as they can
> give
> > > up
> > > > > on
> > > > > the "when it's good".
> > > > >
> > > > > If we were trying to more closely match what actually happens
> with
> > > > > measurement based location determination, or which GPS is the
> > > easiest
> > > > > example to work with, we would have the protocol deal with start
> up
> > > > > issues.
> > > > > The characteristic of GPS is that there is a significant start
> up
> > > > time,
> > > > > but
> > > > > after that, location updates equivalent to "now" is what you
> get.
> > > > >
> > > > > Most triangulation mechanisms have some kind of start up, most
> have
> > > > > updates
> > > > > equivalent to "now", but some don't (some triangulation really
> is a
> > > > > triggered measurement, which has finite, non trivial time to
> > > complete
> > > > a
> > > > > measurement).
> > > > >
> > > > > When there is a delay for an accurate measurement, the server
> knows
> > > > what
> > > > > the
> > > > > delay is. If we were trying to really get both sides to do
> > > something
> > > > > reasonably optimal, we'd have the server tell the client what it
> can
> > > > do,
> > > > > and
> > > > > have the client react in some reasonable way.
> > > > >
> > > > > When there is a startup issue, and sometimes when there is a
> > > > significant
> > > > > time to complete a measurement, there can be intermediate, less
> than
> > > > > full
> > > > > accuracy results. Again, if we were trying to make optimal
> > > > > applications,
> > > > > the server would have some way to tell the client what it could
> do,
> > > > and
> > > > > have
> > > > > the client react.
> > > > >
> > > > > No matter what the measurement methodology, there is very little
> > > > > variability
> > > > > on the server side. It's built to do what it does, and it can't
> > > > > actually
> > > > > vary much. Having the client tell the server what it wants is
> > > > > backwards:
> > > > > the server can't actually react; all it can do is do what it
> does,
> > > and
> > > > > drop
> > > > > some kind of response when the timer expires. Actually, in
> nearly
> > > > every
> > > > > case, it can predict what happens, but that doesn't help the
> client
> > > > any.
> > > > >
> > > > > The client, if it really cares, could react to what the server
> can
> > > do,
> > > > a
> > > > > lot
> > > > > more usefully than having the server react to what the client is
> > > > asking
> > > > > for.
> > > > > If the server tells it that it has a startup problem, and will
> have
> > > > > accurate
> > > > > results in 30 seconds, the client could display some useful
> > > feedback,
> > > > as
> > > > > an
> > > > > example.
> > > > >
> > > > > Finally, most measurement systems have a time/accuracy tradeoff,
> > > > > especially
> > > > > if the target is not moving. The longer you wait, the more
> accurate
> > > > the
> > > > > measurement. If the measurement mechanism is triggered, you
> restart
> > > > the
> > > > > time/accuracy clock. So, asking for a measurement with a
> timeout
> > > > would
> > > > > not
> > > > > allow you to use a triggered measurement with a time/accuracy
> > > > tradeoff.
> > > > > The
> > > > > client doesn't understand that if it either lengthened the time,
> or
> > > > > lengthened the time between requests, it would get more
> accuracy.
> > > If
> > > > we
> > > > > were trying to get both sides to do something optimal, the
> server
> > > > would
> > > > > tell
> > > > > the client that retriggering resets the time/accuracy tradeoff,
> and
> > > it
> > > > > would
> > > > > tell the client what the time/accuracy function looked like.
> > > > >
> > > > > Let me also react to "web servers take seconds". Sure. But
> there
> > > are
> > > > > humans involved. Protocol mechanisms that take seconds are best
> > > done
> > > > > with
> > > > > event notification or call back mechanisms. If you don't do
> that,
> > > you
> > > > > have
> > > > > to use threads or polling, or some other ugliness to not block
> on
> > > the
> > > > > exchange.
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > > > Sent: Saturday, July 21, 2007 12:40 PM
> > > > > > To: Brian Rosen; Stark, Barbara; Mary Barnes; geopriv@ietf.org
> > > > > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > > > > >
> > > > > > Hi Brian,
> > > > > >
> > > > > > I think the fact that you feel the need to quantify "right
> away"
> > > and
> > > > > > "I'll wait" is revealing in itself. Of course "right away"
> > > literally
> > > > > > means zero wait and "I'll wait" is any time up to infinity.
> The
> > > > values
> > > > > > you "prescribe" are based on your here/now understanding and
> > > > > presumption
> > > > > > of specific applications.
> > > > > >
> > > > > > Requesting location in a WCDMA UTRAN can involve relating the
> > > > serving
> > > > > > cell directly to a nominal area of coverage (msec), putting
> the
> > > > device
> > > > > > into soft handoff to collect a set of round-trip time
> measurements
> > > > > from
> > > > > > in-range base stations (a few seconds), or doing A-GPS (up to,
> > > say,
> > > > 30
> > > > > > seconds). Each places different demands on network resources.
> > > > > >
> > > > > > The cell-based location may be adequate for accurate PSAP
> routing
> > > > 67%
> > > > > > while RTT may be accurate 99.9% of time. Other applications
> will
> > > > > > similarly be sensitive to accuracy variations. Tolerance for
> > > > response
> > > > > > delays isn't something you can claim to be able to predict for
> all
> > > > > > applications today and forever.
> > > > > >
> > > > > > It's no good saying that an application that asked for a four
> > > second
> > > > > > response might say "oh - if I'd known I could have had the
> result
> > > in
> > > > > > five seconds, I'd have been OK to wait." If it is OK to wait
> five
> > > > > > seconds, then it should request a response time of at least
> five
> > > > > > seconds.
> > > > > >
> > > > > > As we've explained before, our experience has shown that the
> > > > Low-delay
> > > > > > or Delay-tolerant choices that the 3GPP protocols provide have
> > > been
> > > > > > problematic. At least in that case there has been an
> accompanying
> > > > > > (scalar) accuracy requirement to go along with the QoS. The
> latter
> > > > has
> > > > > > at least facilitated some ability to arbitrate between
> location
> > > > > > techniques and order of fallback. With just a binary response
> time
> > > > > > requirement, it would be impossible to do any arbitration.
> > > > > >
> > > > > > If you assume you know everything now and force a binary
> choice
> > > into
> > > > > the
> > > > > > semantics, then you can't undo that if it's a mistake. If the
> > > > > semantics
> > > > > > support a scalar response time and it turns out that 100msec
> and
> > > > 30sec
> > > > > > is all anyone ever needs then, at worst, that is what ends up
> > > being
> > > > > put
> > > > > > in all the HELD requests.
> > > > > >
> > > > > > Cheers,
> > > > > > Martin
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > > > Sent: Saturday, 21 July 2007 4:35 AM
> > > > > > To: 'Stark, Barbara'; 'Mary Barnes'; geopriv@ietf.org
> > > > > > Subject: RE: [Geopriv] HELD comment on responseTime parameter
> > > > > >
> > > > > > Hehe
> > > > > >
> > > > > > As you know, I am in the binary "gimme what you got now, gotta
> > > route
> > > > > > this
> > > > > > call" or "I need a good location, I'll wait for it" camp.
> > > > > >
> > > > > > I have a really hard time coming up with a use case where you
> have
> > > a
> > > > > > value,
> > > > > > and not knowing anything about what the other end can do, I
> think
> > > a
> > > > > > value is
> > > > > > pretty useless.
> > > > > >
> > > > > > Please keep in mind that "right away" is order of milliseconds
> and
> > > > > "I'll
> > > > > > wait" can be 30 sec give or take for a typical assisted GPS
> start
> > > > up,
> > > > > > and a
> > > > > > couple of minutes for a cold start GPS. Right away is
> protocol
> > > > > > request/response territory. Anything that has tens of seconds
> or
> > > > more
> > > > > > in it
> > > > > > is an async event notification/call back kind of thing.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stark, Barbara [mailto:bs7652@att.com]
> > > > > > > Sent: Friday, July 20, 2007 2:25 PM
> > > > > > > To: Mary Barnes; geopriv@ietf.org
> > > > > > > Subject: [Geopriv] HELD comment on responseTime parameter
> > > > > > >
> > > > > > > I'm probably opening a can of worms with this comment, but
> I'll
> > > > make
> > > > > > it
> > > > > > > anyway...
> > > > > > >
> > > > > > > There have been discussions elsewhere as to whether it's
> really
> > > > > > > useful/meaningful to specify a desired response time, or
> whether
> > > > > it's
> > > > > > > better to specify that the response is needed right away
> > > > (presumably
> > > > > > for
> > > > > > > routing purposes) or the device can wait a little to get a
> more
> > > > > > precise
> > > > > > > location.
> > > > > > >
> > > > > > > Should we have that conversation here, about this parameter?
> > > > > > > Barbara
> > > > > > >
> > > > > > > *****
> > > > > > >
> > > > > > > The information transmitted is intended only for the person
> or
> > > > > entity
> > > > > > to
> > > > > > > which it is addressed and may contain confidential,
> proprietary,
> > > > > > and/or
> > > > > > > privileged material. Any review, retransmission,
> dissemination
> > > or
> > > > > > other
> > > > > > > use of, or taking of any action in reliance upon this
> > > information
> > > > by
> > > > > > > persons or entities other than the intended recipient is
> > > > prohibited.
> > > > > > If
> > > > > > > you received this in error, please contact the sender and
> delete
> > > > the
> > > > > > > material from all computers. GA623
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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]
> > > > >
> > > > >
> > > > >
> > > >
> > >
> ------------------------------------------------------------------------
> > > > --
> > > > > ----------------------
> > > > > 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]
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > --
> > > ----------------------
> > > 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
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 23 Jul 2007 14:03:15 -0500

This archive was generated by hypermail 2.1.8 : Mon Jul 23 2007 - 15:03:24 EDT