[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ecrit] Suggestion for "performance and reliability" section

Assigning "hard" performance numbers can become arbitrary.  I generally
agree with Mike's suggestion on another thread of using percentages/sigma's.
The FCC basically did this with wireless phase II position location
accuracy.  (And I would suggest non-GPS wireless Phase II systems, e.g.
network-based positioning systems, frequently fall short of the FCC
requirements.  An antidotal observation.)

To my knowledge, NENA has not put numbers on dial-to-ring or ring-to-answer.
If they have, I would love to see a citation.  Their idea is simply to keep
the system in line with what the user typically experiences in their
day-to-day use of the telephone system.  That would be good.  But a large
part of the existing 911 infrastructure in the US falls short of even that
pragmatic approach.

If today's wireline call setup times are bad, wireless call setup times
border on the atrocious.  In my experience a 5 second wireless call setup
(send-to-ring) would be excellent.  I have personally done quite a bit of
wireless 911 testing (from inside PSAPs) and observed many wireless call
setups of 15 seconds, and more.  I doubt the average is much better than
10s.

My point is we shouldn't get too hung up on this detail.  A system that
generally provides a level of performance that is close to what the user
generally experiences using, say, an Internet telephone service, or IM, or
web browsing, will be adequate.  Due to the complexity of routing 911
messages we can expect some additional setup delay, but of course we should
strive to keep this to a minimum.  I'm confident what finally emerges from
this process will prove to be considerably superior to much of the 911
infrastructure that exists today.

Carry on.

Byron

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> Sent: Tuesday, August 02, 2005 11:16 AM
> To: Michael Hammer (mhammer)
> Cc: Byron Smith; ecrit at ietf.org
> Subject: Re: [Ecrit] Suggestion for "performance and reliability"
> section
>
>
> I was not intending to standardize such a value. It just happened to be
> the only number I had available, serving as an upper bound on what's
> reasonable.
>
> Michael Hammer (mhammer) wrote:
> > I don't think it meaningful to put a number on "until human answer"
> > unless you intend to automate humans, or are providing some technical
> > analysis on average call rates and staffing at 911 PSAPs.  The latter
> > would be a good NENA exercise, but not sure if that is in scope of
> > ECRIT.
> >
> > Mike
> >
> >
> >
> >>-----Original Message-----
> >>From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> >>On Behalf Of Henning Schulzrinne
> >>Sent: Tuesday, August 02, 2005 11:57 AM
> >>To: Byron Smith
> >>Cc: ecrit at ietf.org
> >>Subject: Re: [Ecrit] Suggestion for "performance and
> >>reliability" section
> >>
> >>I don't think I mentioned NENA. My source of the information
> >>was the LAPD PSAP (which I visited during the NENA meeting).
> >>The person in charge said that their goal was 10s in 95% (not
> >>sure about the
> >>percentage) from call to human answer. They apparently
> >>tracked this information. In their case, the concern was
> >>primarily human response time, not routing time. Call setup
> >>time in mobile systems often approaches several seconds.
> >>
> >>Beyond these anecdotal numbers, I'm not sure that we'll be
> >>able to rely on existing performance standards and that we
> >>can draw much insight from any number we get, except that
> >>having a gnome looking up the information in an atlas is
> >>likely to be unsatisfactory and that faster is better.
> >>
> >>I also suspect that the only protocol that would likely fail
> >>a reasonable lookup time test, except by pure implementor
> >>stupidity, would be one that walked a geo search tree with
> >>widely distributed servers for each query.
> >>
> >>
> >>Byron Smith wrote:
> >>
> >>>Henning, where do you get the NENA 2s and 10s numbers?  The
> >>
> >>only thing
> >>
> >>>I have found in NENA documents is:
> >>>
> >>>"  9 Call Set-up Time
> >>>     It is recommended that emergency call set-up time not
> >>
> >>exceed the
> >>
> >>>average call set-up time for any
> >>>     other type call made by the customers of that
> >>
> >>particular serving
> >>
> >>>office.
> >>>
> >>>     It is also strongly recommended that in all circumstances the
> >>>caller hear either audible ring tone or a
> >>>     recording alerting them that their call is being processed."
> >>>
> >>>The above is from NENA 03-501.   I have looked for other NENA
> >>>recommendations, but have not found them.
> >>>
> >>>I would appreciate a reference if you have one.
> >>>
> >>>Not that this is terribly relevant: But I would make a small wager
> >>>that more than 50% of the (rural) wireline 911 systems in
> >>
> >>the country
> >>
> >>>fail to meet the above recommendations.  (Probably closer
> >>
> >>to 80%) The
> >>
> >>>observed call setup time for systems that use CAMA trunks
> >>
> >>is usually
> >>
> >>>3-7 seconds dial-to-ring, with 5 seconds being typical.
> >>
> >>Most digital
> >>
> >>>end-office switches make local dial-to-ring setups on the
> >>
> >>order of 1 second.
> >>
> >>>Byron
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: ecrit-bounces at ietf.org
> >>
> >>[mailto:ecrit-bounces at ietf.org]On Behalf
> >>
> >>>>Of Henning Schulzrinne
> >>>>Sent: Tuesday, August 02, 2005 4:08 AM
> >>>>To: ecrit at ietf.org
> >>>>Subject: [Ecrit] Suggestion for "performance and
> >>
> >>reliability" section
> >>
> >>>>
> >>>>I would think capturing the known external requirements as such is
> >>>>helpful. For example, the NENA 2s (dial-to-ring)
> >>
> >>requirement, which is
> >>
> >>>>part of the 10s dial-to-pick-up I mentioned could just be
> >>
> >>captured as
> >>
> >>>>such external guidelines, possibly in a separate "performance and
> >>>>reliability" section. If early implementations, with reasonable
> >>>>assumptions on round-trip times and topology, can't satisfy
> >>
> >>those, we
> >>
> >>>>know we have a problem.
> >>>>
> >>>>Henning
> >>>>
> >>>>_______________________________________________
> >>>>Ecrit mailing list
> >>>>Ecrit at ietf.org
> >>>>https://www1.ietf.org/mailman/listinfo/ecrit
> >>>>--
> >>>>No virus found in this incoming message.
> >>>>Checked by AVG Anti-Virus.
> >>>>Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date:
> >>>>7/28/2005
> >>>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Ecrit mailing list
> >>>Ecrit at ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/ecrit
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>Ecrit at ietf.org
> >>https://www1.ietf.org/mailman/listinfo/ecrit
> >>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.9.8/61 - Release Date: 8/1/2005
>


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit