RE: [Geopriv] Re: Review of draft-busin-geopriv-location-qos-req-01

[Salvatore Loreto <[e-mail]>]

Hi Martin,

thanks for your comments, here some first considerations.
Of course, we are well aware the subject it is not so simple and it
needs to be discussed largely. But also we do believe we have to discuss
it.

regards
Sal


On Sun, 2007-12-02 at 22:17 -0600, Thomson, Martin wrote:
> Hi Sal,
> 
> I have responses to some (not all) of your comments below.
> 
> Thanks,
> Martin
> 
> > -----Original Message-----
> > From: Salvatore Loreto [mailto:[e-mail]]
> > Sent: Saturday, 1 December 2007 12:01 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [Geopriv] Re: Review of draft-busin-geopriv-location-qos-req-01
> > 
> > Hi Hannes,
> > 
> > thanks for your thorough review and useful comments.
> > 
> > see our answers in line
> > 
> > ciao
> > Sal
> > 
> > On Sat, 2007-11-24 at 14:29 +0100, Hannes Tschofenig wrote:
> > > Hi Salvatore, Aeke, Yufeng, Miran,
> > >
> > > thanks for the draft update and for considering feedback provided
> > earlier.
> > >
> > > I read through  draft-busin-geopriv-location-qos-req-01 again and have a
> > > couple
> > > of comments.
> > >
> > >
> > > -- Technical
> > >
> > >    The resulting Location Information is conveyed in existing location
> > >    formats wrapped in GEOPRIV privacy extensions to the Presence
> > >    Information Document Format (PIDF-LO) [RFC4119].
> > >
> > >
> > > [hannes] I guess you need to say more than that.
> > > Reading through the document I got the impression that you would want to
> > > extend the LCP and the LDP to carry the location QoS parameters in the
> > > request and then you want a PIDF-LO back that may contain additional
> > > information. For example, for the response time in the request there
> > will
> > > not be a change in the PIDF-LO itself (expect for the method field since
> > > a different location determination technique was used, for example).
> > 
> > 
> > [Sal]  yes you are correct, our idea is to extend the LCP and the LDP to
> > carry the location QoS parameters in the request.
> > However, in the meanwhile, we don't see the necessity to modify PIDF-LO
> > itself, as the QoS achieved can be induced from the existing
> > information. For example, the age can be induced with timestamp, and the
> > accuracy can be induced from the uncertainty area (described with
> > geometry object).
> > 
> > >
> > >
> > > ### Accuracy:
> > >
> > > You list two parameters for accuracy:
> > >    o  horizontal accuracy
> > >    o  vertical accuracy
> > >
> > > The term "accuracy" has provided a lot of confusion in the past.
> > > Are you sure you mean accuracy or rather confidence. See the discussion
> > in
> > > http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-uncertainty-
> > 00.txt
> > > regarding this topic.
> > 
> > 
> > [Sal]
> > "accuracy", "uncertainty area" and "level of confidence" are relevant
> > concepts.
> > 
> > Our intention is to use "accuracy" to describe the required level from
> > the application perspective, so that proper position determination
> > technology can be chosen by the location server.
> > "uncertainty" and "confidence" is more suitable to described achieved
> > level (for example if a circle is returned in a PIDF-LO, it refers to
> > the uncertainty area),  however it's not so easy to describe the
> > required level with "uncertainty" and "confidence",
> > how to describe the uncertainty area before the actual location is
> > retrieved?
> 
> [MT]  I find the current definition falls short of being implementable.  The same problem exists with 3GPP specifications, 
> which I have found need a great deal of additional (read: proprietary) interpretation.  For a given location estimate, 
> uncertainty can be expressed in several ways; for instance, 30m radius at 60% or 100m at 90%.  Comparing this against a requested 
> "horizontal accuracy" (I prefer "target uncertainty" because it is a more precise term) of 50m is impossible without further context. 
> That is, you need to know both the target uncertainty and the target confidence to properly evaluate whether the estimate is accurate enough.
> 
> [MT] I think that this area needs to be expanded.  Firstly, irrespective of requested "horizontal accuracy", a client should be able to request a certain confidence. 
> A server, as a Location Generator, is better capable of adjusting regions of uncertainty to match a given confidence, since they have the additional information necessary 
> to do this.
> 
> [MT] In addition to this, a client should be able to either specify how, or at least know how, the server is evaluating their "accuracy".  
> That is, the uncertainty is evaluated at a confidence that is either specified by the client or established in standards.


> 
> > We can not simply include the "confidence" in the request as well, for
> > example, we can not just require "confidence over 95%" in the request
> > for an kid tracking application,  an answer with location information
> > that states "child is in Sweeden" fulfill the requirement of 95%
> > confidence, but possibly useless. 
> 
> [MT] It is up to the user/client to decide whether that information is useless or not. 
> They know their requirements best, and so should structure their requests so that they 
> get information in the form that best suits them. For that reason, we need to get the definitions right.


[Sal] yes, I can't that agree "uncertainty" is a more correct term than
"accuracy". 
"Accuracy" is a term inherited from the 3GPP specs. 
It is not a problem at all from our point of view rename if it.

[Sal] MT you are correct in that a Confidence level is needed. 
The problem is that in none of the  3GPP LCS, OMA SUPL or OMS MLP
specifications have capability to define confidence in the request.
Instead it the positioning determination mechanism has an
(implementation specific) setting of Confidence.  It is then assumed
that the application is aware of what confidence is used. 
This has shown to be a far from perfect solution but has so far not
caused enough problems to initiate extensions to the specs. 
Thus the main problem with introducing confidence is that the location
server cannot (at least for the moment) forward it to the positioning
determination entity. Don't think this is a show stopper but if it's
allowed to respond with another confidence level the it acceptable to
include a requested confidence in the QoS.

> 
> > >
> > > ### Response Time:
> > >
> > > As an example, is the functionality in Section 6.1. of
> > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-
> > delivery-03.txt
> > > what you have in mind?
> > 
> > 
> > [SAL] Well, a similar meaning. In mentioned draft it is defined as the
> > time that Device is prepared to wait for a response, while we defined it
> > as the time on Location Server in which it has to (or should) send a
> > response.
> > The reason why we use this later definition is because we assume that
> > Location Server (or LIS in HELD case) cannot estimate how long will the
> > response travel through the network to the recipient (or Device).
> > 
> 
> [MT] "Low delay" and "delay tolerant" are too vague to be useful. If implementations are to interoperate, they need to have a shared understanding 
> of what each token means.  Hence the fact the HELD has a definitive value.  Note that a LIS is not expected to estimate times for network traversal,
>  it should be applying the value when a request is received.

[Sal] Sorry, but we do not use low delay or delay tolerant in the draft.
So I don't see your point here.

> 
> [MT] A second note on this is the application of response time to SIP subscriptions.  I'd be interested in knowing how this value applies to notifications.

[Sal] For SIP subscription it is not of much use. 
A definition could be "Time from when condition of reporting has
occurred to notification being sent"

> 
> > > ### QoS class
> > >
> > > To me this seems to correspond to the functionality listed in Section
> > > 6.2.1. of
> > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-
> > delivery-03.txt
> > > regarding the "exact" attribute
> > 
> > 
> > [Sal]: Yes, it has similar functionality, but it's used to complement
> > different parameter.
> > It is referring only to the degree of adherence of location Type
> > parameter (geodetic, civic, any).
> > We propose the QoS class to define the degree of adherence of horizontal
> > and vertical accuracy, response time, and age parameters.
> 
> [MT] I'd like a more stringent definition of what you have in mind. In my view, the QoS is either met or not. 
> Recent 3GPP standards introduce a concept that is worth reusing.  The "Accuracy Fulfillment Indicator" places 
> control in the hands of the client by ensuring that location information is always provided, but with an indication of whether QoS was met.
> 
> > > ### Age
> > >
> > > Regarding "age" we currently have only the following functionality
> > defined:
> > > See Section 4.2 of
> > > http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-
> > context-01.txt
> > > This section defines the concept of snapshot URIs, i.e., when the Target
> > > (or an entity
> > > on his/her behalf) requests a location URI then it may express
> > > additional constraints.
> > > In this case it means that the location URI reveals only the location of
> > > the Target
> > > at the time when the location URI was created.
> > >
> > > Reading through that part of the
> > > draft-winterbottom-geopriv-held-context-01.txt document I realized that
> > > it wasn't
> > > described in such a way that one could use it with the LDP as well. This
> > > is certainly
> > > not nice.
> > 
> > [Sal]
> > "age" is used to limit the freshness of the location information
> > included in the response message, can be express like "Provide me the
> > current or last known location of the target if the known location
> > information is not older than ..." (as long as other QoS defined are
> > met)
> 
> [MT] Age is a useful parameter when caching is involved.  Providing this parameter can tell a LIS whether or not to re-calculate location information. 
> We haven't talked about caching to date.

> 
> > >
> > > I do wonder, however, what values for age would be reasonable.
> > > Currently, we
> > > essentially only have two states, namely:
> > > a) Provide me the location of the Target at the time
> > > when the location URI was created.
> > > b) Provide me the current location of the Target.
> > >
> > > You seem to desire more functionality. Could you be a bit more specific
> > > of what you
> > > would like to see?
> > >
> > > When the response is sent then it includes a timestamp field. This
> > > timestamp in
> > > the PIDF-LO indicates when the PIDF-LO document was created. Is this
> > > indication
> > > good enough for you?
> > 
> > [Sal] Yes
> > 
> > 
> <MT:SNIP/>
> > >
> > >    1.1)  Geopriv MUST specify Location QoS Information, both in syntax
> > >       and semantics, that SHOULD be insert in the LCP and LDP request;
> > >       the Location QoS information MUST be supported and understood by
> > >       the Location Recipient and the Location Server.
> > >
> > > It is not entirely correct to say GEOPRIV here since the requirements
> > > refer to a
> > > specific protocol. Hence, it would be useful to list the protocol that
> > > needs to
> > > have the extension defined. You may add this information to Req. 2.
> > >
> > > Since the Location QoS Information is supposed to be an optional
> > > extension one
> > > cannot mandate that it is understood by the Location Recipient and the
> > > Location Server.
> > 
> > 
> > [Sal]: this is maybe misinterpreted.
> > The presence of the Location QoS Information is optional not the
> > extension – meaning, if Location QoS Information is not present in the
> > request, the Location Server may return Location Information with any
> > quality.
> > If Location QoS Information is present, the Location Server must know
> > what this means and act accordingly.
> > If Location Server does not understand this information it should return
> > an error indication.
> > Maybe this is not so clear in the draft so we should add these sentences
> > to the Requirements chapter.
> 
> [MT] I don't like this approach because it forces servers to implement QoS support. A client that expects a failure if QoS is not 
> met is likely to make assumptions, which do not hold when the server doesn't understand the extension.  As a protocol extension, 
> it should be optionally supported by all parties.

[Sal] yes sure, but if we let it to be optional also in the server, we
have to define a way to let the client aware if the server support it or
not.
I mean, if we consider the QoS be optionally supported by all parties,
which is the correct behavior when a Client request a location with QoS
to a Servet that doesn't support QoS?
should the server reply with something error like not supported
extension?
or instead it should provide the location adding just a parameter or a
tag saying "this location has been calculate without taking care of the
QoS because I don't understand it"

> 
> > 
> > >
> > >
> > > Ciao
> > > Hannes
> > >
> > 
> > 
> 
> ------------------------------------------------------------------------------------------------
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv