RE: [Geopriv] Response time use cases (was: HELD commentonresponseTime parameter)

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Wed Aug 08 2007 - 18:29:34 EDT

Hi Ted, I have compromised as far as making the parameter optional and there being default semantics for that case - which meets everybody else's preference anyway. I am not willing to compromise such that the LIS can only infer a binary condition and I don't think there's a halfway house. That's actually not a compromise; it's exactly what I'm saying isn't adequate. What if there are three or more possible results at staggered intervals? How does the LIS know when it should stop? Why aren't LIS implementors allowed to have more than two ways of working out location - and users to correspondingly benefit from arbitrary levels of accuracy rather than just bad/fast and good/slow? I don't think there is anything wrong with a server that only has two speeds and converting a scalar time parameter into this "pool". It's perfectly consistent with the semantics. Cheers, Martin -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Thursday, 9 August 2007 3:55 AM To: Dawson, Martin; Brian Rosen; Lisa Dusseault; Mary Barnes Cc: geopriv@ietf.org; Henning Schulzrinne Subject: RE: [Geopriv] Response time use cases (was: HELD commentonresponseTime parameter) At 7:30 PM -0500 8/7/07, Dawson, Martin wrote: >I should have said, sorry Brian, thank you for being prepared to accept >the parameter anyway. I guess this is one data point for consensus that >passes Henning's non-advocacy test? > Consensus is often based on compromise. Are you willing to compromise here? At one side, we have a willingness for two times: now and "when you have a good answer" (for some value of good). You and James are arguing for arbitrary times to be supported. Is there something between arbitrary and 2 that actually meets the real use cases here? I think we can agree that being able to express a time 2 years out is not useful. Possibly we agree that expressing a time as 1 or 2 seconds is so close to "now" in a system with any network slop is not greatly different. Are there any other constraints we can put in here to avoid this turning into the protocol expressing a constraint that the typical server simply will put into one of its general pools of now, soon, and "when you know"? regards, Ted >Cheers, >Martin > >-----Original Message----- >From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >Sent: Wednesday, 8 August 2007 10:27 AM >To: Brian Rosen; Lisa Dusseault; Mary Barnes >Cc: geopriv@ietf.org; Henning Schulzrinne >Subject: RE: [Geopriv] Response time use cases (was: HELD >commentonresponseTime parameter) > >Again - experience is not considered relevant, however: > >In cellular, accuracy is a well established QoS parameter in the >request. It is used for technology arbitration. However, every LBS we >have encountered wants the "strict-QoS" turned off for accuracy. That >is, if the requested accuracy cannot be returned, then they'd still like >to be given whatever result is available. Regardless, they all have >strict requirements about the maximum time that a result should take. > >Since geodetic location should include uncertainty if accuracy is going >to be communicated, and civic addresses are at a self-evident level of >granularity, then the client is able to asses the result for themselves. > >I actually think there is a significant qualitative difference with >respect to when things like desired response time and available accuracy >are known - and this is what empirical experience is highlighting. > >I have no objection to having an accuracy QoS parameter Brian. I don't >consider it to be useful so I haven't been asking for it. If somebody >else thinks it would be useful to them, I wouldn't throw barriers in >their way. I do think that the semantics will need to be clear with >respect to how strict that criterion is. That is, should a result be >provided or not if the LIS cannot provide the requested accuracy. > >Cheers, >Martin > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Wednesday, 8 August 2007 10:12 AM >To: 'Lisa Dusseault'; 'Mary Barnes' >Cc: geopriv@ietf.org; Dawson, Martin; 'Henning Schulzrinne' >Subject: RE: [Geopriv] Response time use cases (was: HELD comment >onresponseTime parameter) > >In your example, is the seven seconds a cold start time: you open your >laptop in a new location, and you will wait 7 seconds to avoid typing >your >location manually? If it is, then you have somewhat of a use case. >The 7 >seconds will actually be useful for a "quick fix" kind of location >measuring >system. On the other hand, what accuracy do you need? > >Actually the biggest part of the problem is that we all understand there >is >a speed/accuracy tradeoff, but somehow the proponents only want to talk >about speed. I think there are many more use cases for a specified >accuracy >than a specified response time. > >If 300 meters or so of accuracy is enough, then a quick fix might work. >If >you need to know an accurate civic location (street address), it won't >work. > >I think the Boolean is a good start. I think 99% of applications will >find >it acceptable. I think we'll need an accuracy parameter before we need >a >time parameter. > >OTOH, I won't go to the mat on it. If we need to compromise, I'll >compromise. It's not that important; it's just, in my opinion, useless. > >Brian > >> -----Original Message----- >> From: Lisa Dusseault [mailto:lisa@osafoundation.org] >> Sent: Tuesday, August 07, 2007 7:55 PM >> To: Mary Barnes >> Cc: geopriv@ietf.org; Dawson, Martin; Henning Schulzrinne >> Subject: [Geopriv] Response time use cases (was: HELD comment >> onresponseTime parameter) >> >> For what it's worth, I get the end-user use cases now, although I >> don't always understand the back-end architecture as it affects the >> information available and at what time delay, and I don't yet see >> how the use cases dictate one particular architecture. >> >> Here's my own use case variation that is neither "ASAP" or "AGAP": >> - Twitter users could have a location publishing and friend >finding >> application, usually to be used on a mobile device, which may be a >> laptop, which may sometimes be connected to a physical network but >> sometimes be 802.11 and sometimes cell. Ideally this application >> would get a civic location because "nearby" is different when you're >> in Northern Ontario or driving down a highway than when you're in >> downtown San Francisco on foot. Coordinate location could be a >> fallback. >> - For this application, when running as an unattended location >> publishing process, no timeouts are needed. However when the user >> wants to do something active and the location is not yet known, users >> are willing to spend an average of seven seconds of wait time in >> order to avoid typing in a location manually. For times above seven >> seconds, the application should just let the user type in a location. >> >> This use case, like many others, could be handled a number of ways. >> 1. The application to set its limit to "infinite" or "7s" depending >> on context, and send that limit in the location request to the >> server, aka the main proposal geopriv is considering >> 2. This particular use case could be handled by asking for a civic >> location and drop the connection (or at least changing the UI to >> prompt text entry) if a time limit is reached. If the civic location >> doesn't return within a few seconds the client could send a second >> request for geo, and the geo request could also be dropped. >> 3. The client could ask the server what location information it has >> available and at what expected time delays in one request-- like >> asking for an index-- then in a second request ask for one of those >> location responses. If all the times are too long, the client goes >> straight to text entry without even waiting seven seconds. >> 4. Hybrids of the above solutions... >> >> I'm sure there's more approaches, and I can't see how we could gather >> use cases in sufficient detail to really dictate a choice of approach >> since this is standards work, not a spec for one particular >> application. I'm not sure further discussion on use cases is going >> to sway technical choices though it may sway consensus on whether to >> address the response time problem. >> >> The question of what is easiest to do in HTTP, and what works best >> with proxies and other intermediaries, is somewhat more conducive to >> an answer, although the answer still varies depending on whether you >> have more or less control over the client or the server code bases. >> >> The question of whether we have a consensus to address any response >> time use cases at all, or the question of what approach we have a >> consensus to use assuming the first consensus, is even more conducive >> to an answer, that is if we're ready to try to find that consensus. >> >> Lisa >> >> >> On Aug 7, 2007, at 4:02 PM, Mary Barnes wrote: >> >> > We didn't reach consensus at IETF-69, per the minutes and the >> > discussion >> > captured in the Jabber log (at the end): >> > http://www3.ietf.org/meetings/ietf-logs/geopriv/2007-07-25.html >> > There were certainly folks that were okay with the compromise, but >the >> > APP area advisor mentioned that the responseTime wasn't compatible >> > with >> > HTTP architecture and she wanted more use cases. And, the >discussion >> > that has continued on the list since IETF-69 also doesn't seem to >> > indicate consensus had been reached (i.e., I didn't see the >opponents >> > backing down and agreeing to the compromise). I'm still struggling >> > myself to understand the use cases provided, as like others, I >> > can't see >> > how the client can know what time is acceptable. I understand that >> > there are locations that take varying amounts of time to gather and >> > that >> > a client might have a particular preference for a more accurate >> > location >> > depending upon the situation. That all said, I don't object to the >> > current specification of the responseTime in the document, as it is >> > optional and quite loosely specified, for example: >> > "The value of this attribute is indicative >> > only, the LCS is under no obligation to strictly adhere to the >time >> > limit implied; any enforcement of the time limit is left to the >> > requesting Device." >> > and: >> > "The LCS MUST provide the most accurate LI that can be determined >> > within the specified interval. This parameter could be used as >> > input >> > when selecting the method of location determination, where >multiple >> > such methods exist." >> > So, in the end, I can't see that it will do harm, but the concept of >> > time does seem arbitrary given the objective (to be able to get a >> > location with a certain level of accuracy). >> > >> > Mary >> > >> > -----Original Message----- >> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >> > Sent: Tuesday, August 07, 2007 2:14 PM >> > To: Richard Barnes; Henning Schulzrinne >> > Cc: geopriv@ietf.org; Dawson, Martin; Barnes, Mary (RICH2:AR00) >> > Subject: RE: [Geopriv] HELD comment on responseTime parameter >> > >> > >> > This is what I believed that the consensus was also. >> > >> > >> >> -----Original Message----- >> >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> >> Sent: Tuesday, 7 August 2007 10:24 PM >> >> To: Henning Schulzrinne >> >> Cc: geopriv@ietf.org; Dawson, Martin; Mary Barnes >> >> Subject: Re: [Geopriv] HELD comment on responseTime parameter >> >> >> >> I thought that there was some agreement on the compromise proposal >to >> >> keep the responseTime parameter, but make it optional and make the >> >> default to return ASAP. Do people have disagreements with that? >> >> >> >> --Richard >> >> >> >> >> >> >> >> >> >> Henning Schulzrinne wrote: >> >>> As I stated before, the basic IETF protocol design rule is that >> > adding >> >>> features requires rough consensus. I don't see such rough >consensus >> >> here. >> >>> >> >>> On Aug 7, 2007, at 4:37 AM, Dawson, Martin wrote: >> >>> >> >>>> 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 >> >>>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> >> _______________________________________________ > > 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 Wed, 8 Aug 2007 17:29:34 -0500

This archive was generated by hypermail 2.1.8 : Wed Aug 08 2007 - 18:31:33 EDT