Subject: RE: [Ecrit] Final comments on ecrit-requirements-00

From: "Roger Marshall" <[email-masked]>
Date: Mon, 17 Oct 2005 16:59:36 -0700

Tom:
Thanks for these comments.  See my responses in-line.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tom-PT Taylor
>Sent: Monday, October 17, 2005 12:44 AM
>To: ECRIT
>Subject: [Ecrit] Final comments on ecrit-requirements-00
>
>I didn't realize I was so close to finishing, or I would have 
>put this together at the last stopover.  The page count was 
>misleading ...
>
>General remark:  It's probably time to get rid of the old 
>requirement numbers.  I think the ordering and number of 
>requirements will be fairly stable from now on, and the old 
>numbering has been thoroughly messed up in some sections.
>
>I31 and I31b: I'd suggest I31 should come before I4, and I31b 
>is in the same group.

I will plan to do this on the next draft, unless there is an
overwhelming outcry against.

>
>I39 doesn't make any sense in the general context of call 
>setup.  Surely it doesn't imply that a call already set up 
>will suddenly be yanked off to another PSAP based on more 
>accurate data.  I'd suggest the relevant aspect is covered by 
>I42, and the rest is a matter of what is presented to the call taker.

I think you're right, that we should be clear as to what implications
are stated within the motivation. I39 itself is general (a good thing).
How's an update can be used, either during call signaling or afterward,
I'd rather not address with this requirement. 

I39.  Location Updates: It SHOULD be possible to have updates of
location.

Proposed new motivation text:

Motivation: Updated location information may have an impact on PSAP
routing.  In some cases it may be possible to redirect that call to a
more appropriate PSAP (some device measurement techniques provide quick
(i.e. early), but imprecise "first fix" location).

>
>-------------
>
>On the performance objectives: You've made a start, but we 
>have to take it a bit further.  An old teletraffic engineering 
>trick is to assume that probabilities along a path are 
>additive.  This is a reasonable assumption for low 
>probabilities.  To show how it applies here:
>
>You've declared a total latency to ring-tone objective with a 
>set of probabilities for given delays.  BTW you've assumed a 
>normal distribution of delay probabilities,likely not the true 
>model, but that means one of your objectives will be more 
>binding than the others.
>Let's take the 8-second delay probability (1% more than 8s) as 
>a working example.  We have to allocate that 1% to different 
>components of the total setup process.  Since we're 
>concentrating on the mapping protocol at the moment, one 
>possible allocation is:
>
>- probability of delay > 8s within the mapping operation: 0.1%
>- probability of delay >8 s within all other segments of call 
>setup: 0.9%
>
>Note the implicit assumption that there is negligible 
>probability that neither segment takes as much as 8 seconds 
>but the sum is > 8 seconds.
>That isn't really the case, but the overall results will 
>behave as if it were at low probabilities.
>
>That said, the appropriate allocation is a matter of 
>economics.  We have to model each subsystem and determine how 
>cost varies with the allocated probability.  That typically 
>involves looking at the economics of hypothetical reference 
>connections.  Looks like a good exercise for a student.
>
>Meantime, as a starting point, an allocation of 0.1% 
>probability that the mapping process will take more than 8 
>seconds feels about right to me.  That's what I'd suggest you 
>add to your "latency to ringtone"
>objective.
>
>As for "latency to operator": the difference from "latency to ringtone"
>is partly media propagation time, but mostly a matter of PSAP 
>staffing levels.  Neither relates to performance of the 
>mapping operation, so I'd suggest it is redundant in our context.

Tom, this idea of trying to specify this within this requirements draft
was controversial at Paris, and is probably still so.  More than
anything else, though, I think you've pointed out that a lot more
thought could be put into these numbers and how we think about
comparitive performance.  

Therefore, I propose to remove this performance section in the next
draft.  Is there agreement to this move?

Roger Marshall

>
>Tom Taylor
>
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 18 Oct 2005 21:13:39 +0900

Sorry, I still don't see how a location update can affect call routing,
unless you are saying the setup should wait several seconds in case an
update comes along.  Unless that is what you mean, I39 is irrelevant to
the routing process -- any location update will come after setup has
been launched.

Roger Marshall wrote:
...
> (i.e. early), but imprecise "first fix" location).
...

---

From: Andrew Newton <[email-masked]>
Date: Tue, 18 Oct 2005 18:04:04 -0400

> draft.  Is there agreement to this move?

I agree with this.

-andy