RE: [Geopriv] HELD comment on responseTime parameter

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Mon Jul 23 2007 - 02:09:18 EDT

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
Received on Mon, 23 Jul 2007 01:09:18 -0500

This archive was generated by hypermail 2.1.8 : Mon Jul 23 2007 - 02:09:36 EDT