Re: [Geopriv] Response time use cases (was: HELD comment on responseTime parameter)

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

At 4:55 PM -0700 8/7/07, Lisa Dusseault wrote:
>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.

Your statement "Ideally this application would get a civil location because "nearby" is
different..." doesn't quite make sense to me. "Nearby" is a social measure that
does vary a lot (my grandparents' farm was 26 miles from our house in town and it
was "way out in the boonies"--too far for us to see them except some weekends;
I'll commute the same amount each way today), but that isn't really related
to how the locations are expressed. My grandparents farm was the same
distance out in the boonies whether expressed as a distance, coordinates,
or civic location.

> - 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.

Citation, please? Or are you postulating this for the thought experiment?

>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

The basic problem with this approach is that the server has no idea how much of
the time has already been consumed in other activities or will be consumed by
the return trip. If the application expresses it as N seconds, based on some UI
constraint, the client has to lop off an arbitrary amount for network activity to correct
for that. For something based on TCP where retransmission over a wireless link
may need to occur before the data returned is actually presented to the
application layer, deciding what to lop off is a non-trivial problem.
For one thing, I now have to present some basic idea of link characteristics to
the application. Where do I stop with that? Does the appplication need to know the
link is tunneled via a VPN, as well as the fact that it is 802.11? Does it need to know
that the host is using triangle routing with MIP, rather than a locally assigned address?
Does the client presume that the other end of the flow is on a perfect, local link?
Or presume it is some random place in the topology?

You can ignore that, and build some general slop into the system. In that case
7s becomes "soon" as opposed to "right now" or "whenever".

>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.

Dropping the connection would not make much sense here; at worst, the client
has a recent location to work with for the next prompt (especially valuable for
something that is nomadic, rather than truly mobile).

>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

The problem is that the server may well not know this indexed data; it can, at most,
give general ranges of the time it *might* take. If you wanted to add a parameter
to the "immediate fix" request that allowed the server to give estimates on what
the time for a complete request would be, I think that would be harmless, though
not terribly useful. I think burning a round trip to ask for the estimates without
returning any location is likely to be a bad idea, though.

You're also missing the battery & data channel burn aspects of this. A mobile
system could continually ask for this data pre-need, so that the application
can have it whenever it is wanted. In a big-battery 802.11 equipped device,
it might even be willing to do so; the resulting use of data channel and battery
aren't that big a deal. For a small, mobile device, though, that's not a great
use of either resource, and it is very unlikely.

                        regards,
                                Ted
>.
>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

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

This archive was generated by hypermail 2.1.8 : Wed Aug 08 2007 - 13:52:17 EDT