RE: [Geopriv] HELD comment on responseTime parameter

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Sun Jul 22 2007 - 02:12:38 EDT

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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sun, 22 Jul 2007 01:12:38 -0500

This archive was generated by hypermail 2.1.8 : Sun Jul 22 2007 - 02:12:59 EDT