Re: [Geopriv] Signaling versions in 3825bis

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Fri Apr 17 2009 - 01:15:53 EDT

In the interests of closing this issue, Richard and I have just discussed this issue at some length.

I will endeavour to be value-neutral in this email. I will follow up with my own conclusions some time later.

Option 1: Version tag. A tag is included will cause clients that don't understand the new encoding to reject the message. Regardless of how this is selected, the point is to force this rejection - to prevent the client from interpreting the data incorrectly. Currently, this would involve adding a new datum that clients wouldn't understand, forcing them to reject the data.

Option 2: No version tag. The alternative is to avoid the version tag and risk having the data misinterpreted.

First, the truth tables.

There are two tables, showing all combinations of 3825 (-) and 3825bis (bis) for when a version tag is included and when one is not.

Client Server Result
- - OK - not possible
- bis reject - client rejects option
bis - OK - client can interpret
bis bis OK

Client Server Result
- - OK
- bis wrong interpretation of uncertainty
bis - wrong interpretation of uncertainty
bis bis OK

Both options have negative consequences. Therefore, we need a way to arbitrate.

Let's try a little old-fashioned risk analysis. Cost of each approach is the probability of the negative event multiplied by the cost of the event. I'll use symbols - you can assign your own values and make your own judgement based on your set of values.

  Pc = Probability of having an old client.
  Ps = Probability of having an old server.
  Pi = Probability that resolution/uncertainty is used and relied upon by the client.
  Cr = Cost of rejecting the option.
  Cw = Cost of misinterpreting the uncertainty.

Therefore risk analysis assigns the following costs:

  Version tag = Pc * Cr
  No version tag = (Pc + Ps) * Pi * Cw

Ultimately, assigning values to these is going to be somewhat subjective, but here are the arguments and conclusions we came to:

  (Pc << 1) The number of actual deployments of implementations that use the 3825 is known to be quite small... some say non-existent.

  (Cr > Cw) In general, it's worse to have nothing than to be wrong(ish). As already discussed, a shift (up to 50% in distance, 75% in area) in uncertainty might not be a problem. On the other hand, rejecting the entire option outright could prevent use of location information at all.

  (Ps < Pc) Probably. That is, it seems likely that a server is upgraded ahead of all its clients. There are exceptions.

Even though it's not a good basis for design, the emergency issue might be important to you. Current accepted wisdom states that wrong location is better than no location at all as long as it isn't too wrong. You might to assign values such that (Cr >> Cw)... An error in interpreting uncertainty is not good, but at least you get a call through.
        
So, examples:

If I assign: Ps = Pc = 5%, Pi = 80%, Cr = 1.2, Cw = 1
  A version tag is considered a good choice at a cost of 0.06 over a cost of 0.08 for no version tag.

Or I could assign: Ps = 5%, Pc = 3%, Pi = 60%, Cr = 1.5, Cw = 1
  No version tag is the conclusion at a cost of 0.048 over a cost of a tag at 0.075.

Don't let my examples influence your own evaluation. Choose your own numbers. I just picked a set of numbers that worked for either position.

--Martin

------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv
Received on Fri, 17 Apr 2009 00:15:53 -0500

This archive was generated by hypermail 2.1.8 : Fri Apr 17 2009 - 01:16:06 EDT