RE: [Geopriv] HELD comment on responseTime parameter

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Tue Aug 07 2007 - 04:37:17 EDT

I'm hoping that the silence might mean that people are feeling more sympathetic to supporting this parameter - with the agreed default semantics. Am I overly optimistic? Cheers, Martin -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Wednesday, 1 August 2007 9:12 AM To: Rohan Mahy Cc: geopriv@ietf.org; Mary Barnes Subject: RE: [Geopriv] HELD comment on responseTime parameter Hi Rohan, Per the key question: How does the client and/or application know that it is OK to wait 5 seconds? Can you describe an example use case (a vignette) with a sample time? I think the only entity that can possibly know how long it is OK to wait is the client/application. The location server certainly doesn't know what the context of the application is. All I'm asking is that the client be able to inform the server of this so the server can optimize the result for the client. Some vinaigrettes :) : 1. A "local services" application running on a PDA is asked to provide the nearest teller machines to the current location. It can provide visual feedback to the user that it is determining their current location. It thinks that a minute is a reasonable amount of time to ask the user to wait in this context. The application sends the location request to the LIS telling it that it is prepared to wait up to a minute for the response. The LIS provides the optimal location value - which may take considerably less than a minute. 2. A location-based interactive gamer wants an updated list of all fellow team members in the current geographical vicinity. It's a tactical message. The application thinks this needs to be accomplished within ten seconds. It requests the game server to get all team members to update their location. All team member application instances request a location update with a five second response time. If no location is retrieved, the application returns the last known location, suitably tagged as such, for display at the requesting player's terminal. 3. A VoIP call is being placed that is subject to location based routing. The call is urgent. The VoIP application requests the current location from the LIS and tells it that it needs a location in 2 seconds for incorporation in the SIP invite. 4. A pizza delivery application (having been accurately routed to) wants a more accurate location for pizza delivery. The pizza dispatcher asks the caller for their current accurate location. The caller consults the auto-location determiner application on their PDA and tells it to see what it can work out in the next 30 seconds. The LIS applies optimal location determination technology given that time frame. Now, to turn things around, I'd actually like an example of a client/application that wouldn't apply some sort of timeout to the request that it sends to a LIS. All I'm asking is that this particular piece of information be passed on to the LIS to facilitate the location determination process. We'd already agreed on some reasonable default semantics where an application doesn't provide this guidance. The fundamentals of the objection escape me. Cheers, Martin -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com] Sent: Wednesday, 1 August 2007 7:21 AM To: Dawson, Martin Cc: Brian Rosen; Stark, Barbara; Mary Barnes; geopriv@ietf.org Subject: Re: [Geopriv] HELD comment on responseTime parameter Hi, One important question inline... On 7/21/07, Dawson, Martin <Martin.Dawson@andrew.com> wrote: > 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. How does the client and/or application know that it is OK to wait 5 seconds? Can you describe an example use case (a vignette) with a sample time? In the medical world, labs are often asked to provide results in roughly these time scales: STAT: immediately. drop everything. ASAP: As Soon As Possible. Do it now unless you are doing something STAT Next Available: when you would normally get it done. Double Check: Be extra thorough and rigorous. Take as long as you need. I am wondering if this is more along the lines of what the client wants to specify. thanks, -rohan > 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] > > > > _______________________________________________ > 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 ------------------------------------------------------------------------------------------------ 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, 7 Aug 2007 03:37:17 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 07 2007 - 04:37:36 EDT