Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 07:32:47 -0400

Congestion at the PSAP is much less likely in next generation emergency
calling networks.  They will be designed to handle this kind of event much
better than current ones.  Calls will be able to be answered by other PSAPs.
The goal is to build the networks such that in events larger than the
"Katrina" disaster, all calls can be answered.  Conventional networks may
indeed congest, and of course IP networks can congest.  We will have
capacity for tens of thousands of calls to be answered simultaneously.  That
is millions per hour.  All networks have limits, and these will too, but
they will be orders of magnitude larger than they are now.

Whether, and in what conditions, these facilities are used will be local
decisions, but the networks will be designed to be able to answer every call
that gets to the emergency services IP network.

The emergency services networks will have call admission controls, and the
media capacity will figure into these admission controls.  We would like
DiffServ marking of emergency calls, and slight priority over normal network
traffic for them, but don't expect that most access networks would provide
that.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 3:52 AM
> To: Henning Schulzrinne
> Cc: [email-masked]; Rosen, Brian; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCP without giving away the store
> 
> The circumstances you detail are more likely to have an impact on the
> ability to make calls at all. Significant congestion or disruptions to
> quality of service in the access network are likely to render media
> streams inoperative before they break the simple act of location
> retrieval.
> 
> There is an analog in cellular. Mass-calling events arising from
> significant localized emergency events cause congestion in the serving
> cells of those networks as well. Before they do that, however, they
> cause congestion at the serving PSAP(s).
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, 17 April 2007 3:35 AM
> To: Dawson, Martin
> Cc: Rosen, Brian; [email-masked]; [email-masked]
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
> endpointcentric LCP without giving away the store
> 
> Location determination is not likely to be the major delaying factor,
> although it can be under the wrong circumstances. If there's even
> modest packet loss, any TCP connection establishment can be delayed
> significantly, due to the exponential backoff retry. We'd have to do
> 2 such lookups (L7 and LoST), plus DNS to resolve the LoST-returned
> URL. Thus, we're talking roughly 10 round trip times (2 handshakes
> for TCP, 2 query/response for LoST and L7, plus one round trip for
> DNS). The initial TCP timeout is 500 ms, if I recall correctly and so
> is the DNS timeout, both with exponential backoff.)
> 
> I'm particularly concerned with mass casualty events, where the
> infrastructure is under duress.  Most of the time, none of this will
> be problem; however,  even with modest packet loss rates, there will
> be a significant fraction of calls experiencing delays of one or more
> seconds, which are indeed significant based on the performance
> requirements we were given by the PSAP community.
> 
> The critical timing is determining rough location and the URL lookup;
> this can all be done ahead of the call with no loss of accuracy.
> Thus, delaying PSAP URI determination until call time will indeed
> degrade the timeliness of emergency calls.
> 
> Henning
> 
> On Apr 16, 2007, at 1:08 PM, Dawson, Martin wrote:
> 
> > I really can't buy into the "significantly degrades
> > performance/reliability" argument.
> >
> > Actually, I think that not doing it at call-initiation may cause the
> > more significant degradation.
> >
> > It can't be assumed that the device "knows" that it's not mobile. As
> > Brian mentioned, using Ethernet on a mobile platform (camper, train,
> > plane...) make mobility invisible to the device.
> >
> > I can't imagine any sensibly implemented wireline access location
> > technology that would impose anything more significant than sub-second
> > response for maximal accuracy. For mobile networks, it may take
> > longer -
> > but it's exactly for mobile networks that it's preferable to determine
> > location as close as possible to call origination time (just as is
> > done
> > in cellular today).
> >
> > I suppose that BCP could state that, in the absence of an updated
> > location at the time of the call within the time required, the device
> > may use the last-known location. That is an optimization and not a
> > fundamental principle. A well defined fallback procedure should always
> > be in place.
> >
> > Cheers,
> > Martin
> >
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Tuesday, 17 April 2007 2:54 AM
> > To: Rosen, Brian
> > Cc: Dawson, Martin; [email-masked]; [email-masked]
> > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how
> > to do
> > endpointcentric LCP without giving away the store
> >
> >
> > On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote:
> >
> >> Right.  Good summary.
> >>
> >> However, because at least some networks have to get through Pay to
> >> Play,
> >> we need to provide mechanisms that work.
> >>
> >> The proposal (access networks that want pay to play must provide
> >> LbyR,
> >> PSAP URI and dialstrings seems a workable solution to those networks.
> >
> > This only works for stationary devices, barely, unless there's an
> > event notification mechanism that updates that information,
> > particularly the PSAP URL.
> >
> > Otherwise, you have to rely on call-time queries, which significantly
> > degrade reliability and performance. In that case, you're not
> > providing a service that is equivalent and the customer pays for the
> > provider's pay-to-play dreams with their life and property.
> >
> > Henning
> >
> > ----------------------------------------------------------------------
> 
> > --------------------------
> > 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]
> >
> 
> 
> --------------------------------------------------------------------------
> ----------------------
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 08:32:34 -0400

That is not true. You can still have an audio call at 10% packet  
loss, but you'll get a significant probability of the delays I  
mentioned at that point. During periods of stress, the more  
transactions you need to do, the higher the overall probability of  
failure. You might want to try this in a test bed with a loss  
emulator before making claims.

The whole idea of going IP is to distribute the load among lots of  
PSAPs if there is a regional crisis, such as an earthquake or hurricane.

We've discussed and had rough consensus on this long ago, so I'm  
surprised this comes up again. Maybe it's just convenient to ignore  
when it doesn't fit the agenda of hiding location.

Henning