RE: [Geopriv] ResponseTime

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Tue Aug 28 2007 - 16:52:27 EDT

If the choice - as you seem to be suggesting - is between one bit (inadequate in my estimation) and a full blown profiling, multi-parameter, request and backoff with reference mechanism (overblown, overcomplicated, and impractical in my estimation) then I still haven't got the functionality that I require (a simple scalar response time). Why can't I have this optional parameter in the base spec? What is the semantic difference between this and an optional extension? A client doesn't have to use base spec option and, with respect to this parameter, a LIS can choose to ignore it. Why can't we just have it in the base spec now? Where's the spirit of compromise? The scalar parameter with the default semantics I described cover your requirements as well as meet mine. What's the obsession with limiting communication to a single bit? Also - I don't understand the implication that it can be pre-judged whether a client needs response time or not. The suggestion seems to be that this is "only a wireless problem" - but that doesn't mean it's not a consideration for every client implementation. If I'm implementing an application on a laptop, how do I know whether it is going to be on a wireless access or not. I can't even use the network adaptor as any guide - as has been mentioned, the physical network connection doesn't actually indicate the nature of the Internet access (ref the RV/LAN scenario). Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 29 August 2007 2:56 AM To: peter_blatherwick@mitel.com; Winterbottom, James Cc: 'GEOPRIV'; Dawson, Martin Subject: RE: [Geopriv] ResponseTime The simplest mechanism, if we're starting at mechanism, is just the state of one bit: "roughly now, at roughly whatever accuracy you can do, suitable for routing" or "accurate, in a reasonable time, suitable for display/dispatch/computation", where the interpretation of "roughly" and "reasonable" is up to the server. "Reasonable" is also limited by HTTP and other transport timeouts. The extension is then the parameters, and I think you need more than one, and I think you need a way for the server to tell the client what it could do as well as a event notification/call back mechanism when the delay is more than a couple of seconds. I think we could progress the draft with a single bit, and have extensions, later, for more. I think most apps will do fine with that bit, and the ones that need more, can have more. That is the central question to me: is a single scalar so much more useful than the bit that it should be in the base protocol? I think the answer is no. You have a time/accuracy tradeoff and specifying time with no knowledge of what the curve(s) looks like is inadequate. The question after that is how much mechanism is useful for the next step? I think that it's more than one scalar, it's two or three, with a way for the server to inform the client, and an event/call back mechanism. I think that could be written up in 3-4 pages of text, and it wouldn't be all that hard to agree on the parameters and mechanisms if we agreed on the principles. Brian ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Tuesday, August 28, 2007 11:24 AM To: Winterbottom, James Cc: GEOPRIV; Dawson, Martin 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 "Winterbottom, James" <James.Winterbottom@andrew.com> 27.08.07 21:50                 To:        "Roger Marshall" <RMarshall@telecomsys.com>, "Stuard, Doug" <Doug.Stuard@andrew.com>, "Dawson, Martin" <Martin.Dawson@andrew.com>, "Stark, Barbara" <bs7652@att.com>, <peter_blatherwick@mitel.com>, "Robert Sparks" <rjsparks@nostrum.com>         cc:        "GEOPRIV" <geopriv@ietf.org>         Subject:        RE: [Geopriv] ResponseTime I don't believe that time vs accuracy can be profiled well in this fashion. You don't actually know in many cases how accurate the result is going to be until you have started the location calculation.   Take cell-based location for example; I can go from femtocells with a few metre uncertainty to CDMA boomer cells with 200km radius. Both fall in the 0 or sub-second time category, they could also fall into all of the categories you describe below for accuracy.   So I can have 0 : 2 And a 0 : 200,000   Since no device knows the kind of cell it is attached to every device is going to pick the first one,  2 metre accuracy in no time, and some are going to be sorely disappointed. If you specified a wait time of two seconds only, then those connected to a femtocell are happy, they have almost no wait time. Those connected to the boomer cell wait 2 seconds and get a 50 metre accuracy result. Since they were prepared to wait anyway, they are happy too, because 50m is way better than 200km.   The reality is that specifying the accuracy component becomes moot once you know how long the application is prepared to wait. The same is not true in the reverse direction. Indeed there is no general accuracy to wait-time profile that can be provided ahead of time, for any given wireless network this is a non-deterministic problem.   The LIS will pick the most accurate determination technique available in the time requested, and input to this decision may actually be acquired at the time the request is received. For example if you are connected to a femtocell then I am probably not going to bother to invoke anything else, if you are connected to a standard cell then I might. The point and type of access is important to the LIS here for determination, but it is likely completely unknown to the end-point and in many cases can't be known.   Providing a time addresses these concerns in a deterministic manner that will work across all networks since the time is what the application is tolerant to, and the worst case is known.   I have a need for a responseTime parameter. I am prepared to accept that others only want ASAP, and that others still claim they will want AGAP. I remain sceptical about the last one because this is normally qualified with a comment such as "within a reasonable time frame". However, just because I can't see it, doesn't make it so.   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.   Cheers James   ________________________________________ From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Tuesday, 28 August 2007 7:21 AM To: Stuard, Doug; Dawson, Martin; Stark, Barbara; peter_blatherwick@mitel.com; Robert Sparks Cc: GEOPRIV Subject: RE: [Geopriv] ResponseTime   What about using two independents, or even three variables?     Timing and Uncertainty are two variables that could, (if implemented rightly among the elements which determine location), provide additional control, as well as allow the server to choose among different back-end determination technologies, as Robert mentioned in this thread.   Examples of: 0 : 0 (means give me whatever location you have asap) 0 : 50 (means provide location which is reported as being within a radius of 50m asap) 30 : 50 (means provide a location inside a radius of 50m within 60 seconds)   Coupling what is also done (by some vendors) within Wireless/CS domains today, you could add a third variable, though a 'confidence' parameter is still somewhat misunderstood (and certainly mis-applied), so most might want to set this third value to a constant for now:   30 : 50 : 95 (give me the location with a 50m or less tolerance, determined within 30 seconds with a confidence of at least 95%)   -roger marshall.   ________________________________________ From: Stuard, Doug [mailto:Doug.Stuard@andrew.com] Sent: Monday, August 27, 2007 2:13 PM To: Dawson, Martin; Stark, Barbara; peter_blatherwick@mitel.com; Robert Sparks Cc: GEOPRIV Subject: RE: [Geopriv] ResponseTime Given the practical limits stated, option i) is good Option ii) as stated seems too open ended.  If restated to "as accurate as you can get it within the stated time limit", I think virtually all realistic use cases are covered.   In practice, a number of techniques converge within 20 seconds or so, so you could either wait until the stated time limit, or until (reasonable) convergence is achieved.   Doug     From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Monday, August 27, 2007 4:46 PM To: Stark, Barbara; peter_blatherwick@mitel.com; Robert Sparks Cc: GEOPRIV Subject: RE: [Geopriv] ResponseTime   The semantics of response time are "most accurate you can get within this time".   I think I've seen both defaults proposed. That is, the absence of the response time parameter can be:   i)              As fast as possible at whatever accuracy that results in. ii)             Take as long as you like until you think it's as accurate as you can get it.   Given there are technologies that could see incremental (and diminishingly small) improvements in accuracy for every iteration/measurement - even if it went on all day - the LIS would have to apply its own interpretation of "accurate as you can get it" but that's an invisible judgement as far as the client is concerned.   Obviously both defaults can't apply. To me, logically, a response time of zero would mean as fast as possible (since zero can only have theoretical significance so it might as well have a special interpretation). That would leave option ii) as the default semantic.   Cheers, Martin   ________________________________________ From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, 28 August 2007 6:30 AM To: peter_blatherwick@mitel.com; Robert Sparks Cc: GEOPRIV Subject: RE: [Geopriv] ResponseTime   I think there is a need for a device to be able to ask for a "ASAP" vs. "accurate" response for location to be used when requesting emergency services. If it were totally optional, and not using it means "ASAP", then how does a device request "accurate"? I was suggesting using a default value, like 60 seconds (but hopefully recommended by phonebcp) to mean "accurate". Barbara   ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Monday, August 27, 2007 2:39 PM To: Robert Sparks Cc: GEOPRIV Subject: Re: [Geopriv] ResponseTime Hi, > ... need to hear from more of the group than   > just the folks that were active in the discussion earlier in the month I have stayed mostly out of the debate thus far, so here goes.   I would support response time parameter ONLY as an optional extension.  This for the following reasons: o I do not see value in it for the most part; I expect most applications (including ECS) simply don't need it or it would bring fairly minimal value added.   (I can certainly see some special cases / applications where it might be helpful, hence do see value as optional extension for those.)   o It seems very difficult to make such a parameter specific enough to get the proposed value out of it in any consistent way, o MOST IMPORTANT I desperately want endpoints needing to support HELD for ECS purposes to have an absolutely ruthlessly simple subset of the functionality that they must implement.  The subset must be both small (footprint) and very easy to implement correctly.  Endpoints that want to do more than ECS can add to the simple subset by using extended options, but those that do only the ECS part need to be very constrained.  The value added bar needs to be set very high for the core subset.  The value of response time parameter in ECS does not make that grade for me.   Just to be clear on that last point, I'm not all that concerned about the protocol itself (pretty easy) but more so about the implications to the rest of the implementation: What to do if response does not come back in requested time ... what to do if not at requested accuracy .. what if .. what if ....  And also I have the general concern of "feature creep", of which this is one potential example.   -- Peter .   Robert Sparks <rjsparks@nostrum.com> 27.08.07 12:05                To:        GEOPRIV <geopriv@ietf.org>        cc:                Subject:        [Geopriv] ResponseTime All - Lets push to close on the responseTime question. To do this, I'm going to need to hear from more of the group than   just the folks that were active in the discussion earlier in the month. So far, I've seen a good argument that a server can have different   technologies available for determining location and would benefit   from knowing something about how long a client is willing to wait in   order to choose which one to focus on. There has been a question   about an implicit time/accuracy tradeoff here and a suggestion that   we should explore a more explicit separation of indicating those things. I've also seen a good argument that it is unclear how a client   implementation is going to provide values that would be useful to the   server. Without more clarity around this point, I see discomfort from   several people that the proposed mechanism is an opportunity for   "Unintended Consequences" to rear its head. On rereading the threads, I strongly suspect that there are a set of   assumptions going into arguing for this parameter that haven't been   made explicit yet, and I'd like to try a round of teasing those out   to see if it closes the gap in the discussion. Lets start with these two statements (which I _think_ the folks   pushing for the parameter are assuming are true - correct what I have   wrong please): 1) The clients will provide a useful indication of responseTime from   the server's point of view. 2) Different clients (or different applications at the same client)   will provide different enough values to make the same server choose   different location technologies in servicing the query. I can see the parameter helping a system work as long as the service   has some way to tell the client what to ask for (and I recognize that   means the client has to know what service it's invoking). James  (or anyone else who has deployed or is developing a deployment   of something like this) - do you expect to have some influence in a   deployment over what the clients include in this parameter? Are you   expecting to have a relationship with the vendors providing clients   that lets you hand them values to hardcode, or give you a configuration interface you can use as a service   provider? Or are you expecting that to be entirely outside your control? RjS _______________________________________________ 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] ***** 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. GA622   ---------------------------------------------------------------------------- -------------------- 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]   The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.   ---------------------------------------------------------------------------- -------------------- 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:52:27 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 16:54:31 EDT