RE: [Geopriv] Resolving a design philosophy tension

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Tue Aug 14 2007 - 20:01:53 EDT

Hi Ted, I have not been focussed on any particular application with respect to proposals around a response time parameter. Actually, if I was focussed on one specific application, I'd probably agree with the binary parameter proposal. I consider the scalar response time parameter to be best-basis as opposed to best-fit precisely because it doesn't assume that there can be a common understanding of what "ASAP" means. The binary parameter makes assumptions about the relationship between the client and the server to the extent that it assumes that both know what finite time actually qualifies as "soon". Brian actually felt it necessary to prescribe scalar values that equate to "soon" - and this is, hands down, based on a best-fit presumption. Now - the best-basis approach would also suggest that an "accuracy" parameter is also a good idea. I have not been vocal about having such a parameter but that has not been because of a "best-fit" application perspective. Whether it is for emergency calling, friend-finders, fleet tracking, or local information (nearest ATM) type services, the experience has been that all of these services will take whatever accuracy can be provided within their time constraint. Our mobile location center product has a "strict QoS" switch. Since the protocols don't support the semantics for a client to say - "here's an accuracy target, but give me whatever accuracy you can achieve within my request time limit", we have had to provide the switch that allows the location server operator to provide this default behaviour. If the switch is turned on, the protocol semantics are strictly honoured - a result is only provided if the accuracy target is met. Our experience: "strict QoS" is always turned off. So I'd have to say my view on the "accuracy" parameter is based on empirical experience and not a strictly best-fit approach. As I've said, though, if somebody felt that an accuracy parameter is a good idea, then I'd not stonewall them. I would have an opinion on what the default semantics should be however. The "laundry list" mechanism that Brian proposed is another story altogether. If it's "best-basis", it's on the presumption that the client can actually make any kind of sensible decision on what location technology to deploy. To test the proposition, I'd request that the following location technologies be listed per the suggested scheme: * cell-based location * RTT multilateration * Radio camera * UTDOA Fact is that there is no strict ordering of accuracy for these technologies. Life simply isn't that simple. The process of obtaining optimal accuracy in a given time-frame is a dynamic one. Some methods provide asymptotically increasing accuracy as the integration/sampling period extends. Where the asymptote lies depends on factors that vary from request to request. When the sampling period and number of iterations of an algorithm should cease is not an absolute - it needs to be gated by some other constraint like how long it should go on. Further, the location server needs to make decisions on which technology to invoke, and for how long, based on internal considerations such as resource availability (such as LMU channel measurement functions - how much DSP capacity is available at this instant). This is not something it can sign up to on a contractual basis with individual clients. If the laundry list is "best-fit" then I'd argue that it's based on a bad premise. I don't think the device wants to know about internal LIS capabilities. I think the "best-fit" approach is for the client to communicate in terms which are natural to it - response time and accuracy. Cheers, Martin -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Wednesday, 15 August 2007 7:02 AM To: Winterbottom, James; geopriv@ietf.org Subject: RE: [Geopriv] Resolving a design philosophy tension James, You seem to me to be starting from a specific application: making a phone call for which location-based routing is desirable. HELD, as it is currently described, could be far more general purpose. Try to look at the abstract as if you were reading it for the first time: A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol supports mobile and nomadic devices through Location URIs. The protocol is an application-layer protocol that is independent of session-layer; an HTTP, web services binding is specified. That could be used in a host of application context where location-related services are desired. Not all of those have UIs or users, and not all of those have the constraints of location-based routing in a phone call. I was hoping we could step back and look at the design process a bit. Are we designing just for one application? Or are we expecting this to get re-used in multiple contexts by a variety of systems? I don't want us wrapped around the axle of a meta-discussion, but I was hoping that question would prompt folks to step back up level. I hope that will lead us to the conclusion that the elements of what you want might be needed in lots of places, and that the relationship of those elements might be different in different application contexts. If we can resolve our design tension at least that much, in other words, we might be able to make progress without quite so much treading over the same ground at each design decision. Does that make sense to you at all? Ted At 3:41 PM -0500 8/14/07, Winterbottom, James wrote: >Hi Ted, > >It is not clear to me why best available is any more "basic" than I can >only wait 5 seconds. Best available is still an application definition, >it makes no sense outside of an application context (the fact that it >has a timeout as defined below is proof of the need for a response >time). So if you want an absolute bare-bones basic then should not >support anything other than ASAP. > >Personally I think this is silly, as we know that this will not be >satisfactory for anything that is not tied to a desk. Just looking at >one application, the last time I checked, more calls in the US were >generated from mobile devices than wireline devices, for which the >"basic" functionality described would be unsatisfactory and regress from >existing BCP. I find a proposal suggesting this as the preferred course >unsatisfactory. > >I totally object to the notion of enumerations being provided for ASAP >and AGAP. Experience with using enumerations like this in wireless has >shown this. > >The only arguments that I have heard against the responseTime start with >statements like "I can't imagine...". I think that that is also perhaps >the summary. > >I believe that "best basis" includes the responseTime as it allows >location acquisition BCP in environments, other than the >tethered-desktop, to be at least maintained. That is, I subscribe to the >premise of no-worse than current solutions, the proposed binary approach >below does not fit this requirement no matter how brightly it is >painted. > >Cheers >James > > > > > > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Wednesday, 15 August 2007 2:53 AM >> To: geopriv@ietf.org >> Subject: [Geopriv] Resolving a design philosophy tension >> >> I think there is an underlying tension here on how to do protocol >> design. Let's call the two design philosophies "best fit" and >> "best basis". The "best fit" design philosophy starts when you have >> a very particular application in mind, and you tailor the protocol >> to be the best fit to that protocol. Any bells, whistles, or >application >> UI aspects that are present in the application should be reflected > > in the protocol, so that all of the parties to the application (Client >> and server, peers, multicast groups, what have you) all share >> an exact knowledge of the application's state. >> >> The "best basis" design philosophy says that you build a protocol >> so that it can serve as a basis for many different applications, each >> of which may have different bells, whistles, or application UIs. >> Rather than starting from the application and heading down, in >> other words, you start from the primitives from what you to believe >> to be a class of applications, and put those in. Those primitives >> get implemented by everyone who uses the protocol, for whatever >> application. Any aspects which are specific to a single application >> get implemented as extensions. There's always a tension in this >> design philosophy over which bits are true primitives and which >> are good candidate extensions. Since adopting things which ought >> to be extensions into the core protocol pushes the development >> burden onto everyone, it's a big question. It's even more of a >> question when a particular aspect may have big design implications >> for implementation and deployment. >> >> Many protocol efforts are a blend of these two approaches; >> there are few that are really completely one or the other. Most >> "best basis" protocol efforts are driven by use cases, and most "best >fit" >> protocol efforts recognize that there will be some change in the >> application over time. But the tension between these approaches is >> real, and I believe it is one of the underlying tensions in this >group. >> >> So, we can stop everything and have a giant meta discussion on which >> design philosophy is dominant in this effort, maybe fix up the charter >> so that it reflects that (it's way out of date anyway), and engage in >> whatever crystal ball efforts it takes to see where this work will be >> taken as it moves out of the working group and into the world. Or, >> we can try to talk in each others languages as be we can. >> >> Trying my own hand at interpretation, I hear a "best fit" statement >> like this: "My application has a specific need for expressing a >client >> timeout, >> which is used by the server to pick a level of accuracy which can be >> returned." >> I hear a "best basis" response of "There are two primitives there: >> `desired >> accuracy' and `time a client will wait'. Why are they tied together? >> Wouldn't >> the usefulness/generality of the protocol be better if they were not?" >> The replies to that have been in application/use-case specific terms, >but >> I hear the response essentially as "The application context ties them >> together, >> as the lack of response at a specific time triggers the use of a >different >> mechanism >> (e.g. default routing to a PSAP, in the emergency use case)". I >believe >> everyone accepts that to be true for that specific application, but >that >> there >> is a further concern that this will force *all* deployments to create >> similar >> application contexts that tie the two primitives into a single >> expression. >> >> The proposed compromise, which makes this a core part of the protocol >> (not an extension), but optional, papers over the issue. If this were >the >> end of the design discussion, I would say paper it over and be done. >But >> I am concerned that this design tension will continue to be a problem. >> I'd ask >> each person who has been involved in *this* discussion to strongly >> consider >> how to express this problem and any proposed resolution in terms of >both >> design philosophies. I suspect this will be good practice for later. >> >> To wind down this long-winded statement with full disclosure: I tend >to >> fall on the "best basis" side of protocol design, as I have seen a lot >of >> protocol re-use in my time. Making things re-usable early tends to >avoid >> a lot of pain later, and it means getting primitives right is >worthwhile. >> On this particular issue, I do see two primitives: desired accuracy >and >> client wait time. Having one expressed without the other does imply a >> default >> (Give me the location ($DEFAULT="best available) within 20 seconds) >and >> (Give me 1m accuracy within ($DEFAULT="forever" ), and those defaults >> may look silly in particular application contexts. But that does not >mean >> they are not useful primitives in any context, and they clearly are >> separable. >> >> If we do go the route of separating them, rather than papering this >over, >> then we have to do some real work in describing how to relate the two. >> I think that discussion would be a lot more valuable than the one we >> have been having, and I hope others agree. >> regards, >> Ted Hardie >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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, 14 Aug 2007 19:01:53 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 14 2007 - 20:03:50 EDT