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

From: Ted Hardie ^lt;hardie@qualcomm.com>
Date: Wed Aug 08 2007 - 13:54:54 EDT

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 8 Aug 2007 10:54:54 -0700

This archive was generated by hypermail 2.1.8 : Wed Aug 08 2007 - 13:57:12 EDT