Re: crypto delay (Notes from Non-meeting)

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Tue Apr 02 2002 - 08:59:01 EST

I don't think the crypto delay is a big issue by itself. What tends to
kill you (sorry...) is the delay incurred by extra round-trips and the
increased probability of losses. For example, if you use TCP (for SSL),
losing the first SYN packet will increase your setup delay by three
seconds. Thus, I'm particularly worried about anything that requires
extra connections from either the user agent or the emergency call
center, e.g., to check CRLs or to retrieve certificates. Another problem
is anything that may, with some probability, require retry. For example,
if you encrypt your call request via S/MIME with the ECC's public key,
just to discover that the ECC can't decrypt it for some reason, you've
added one additional round-trip and probabilistically additional chances
of packet loss and retry delays. For some real numbers, see the paper by
Tony Eyers and myself on "Predicting Internet Telephony Call Setup" at
http://www.cs.columbia.edu/sip/papers.html

According to discussions on the 911 list, one common standard for 911
answering times is that 90% of all 9-1-1 calls are answered in < 10
seconds. That's the human call setup delay, not the signaling delay.

Andrew Daviel wrote:
>
> On Wed, 20 Mar 2002, Rosen, Brian wrote:
>
> > 3) Impractical to use
> > takes seconds to verify the signature on the
> > processors in the devices. Cannot add a second
> > to post dial delay
>
> Just how much time is considered important in emergency calls ?
> If there are humans in the loop who don't know each other, or maybe
> even speak the same language fluently, we're talking tens of seconds at
> least, maybe minutes. Emergency services can't put a response together
> that fast, in any case. A few seconds taken to authenticate a location
> and reduce the incidence of false alarms is going to save time and lives
> in the long run.
> There is perhaps an issue if the caller believes the equipment is broken
> and tries to reconnect, or abandons it altogether. This might be obviated
> by some display or audible feedback of call/authentication progress.
>
> --
> Andrew Daviel
Received on Tue Apr 2 08:50:57 2002

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST