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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 16 Apr 2007 13:19:22 -0400

If the LCP guys don't want to include a location URI and dialstring in a
response, then I think we need a new protocol to combine the LCP + LoST
response in a single query to the access network.

I don't have a problem with that, although it's just one more thing the
endpoint has to implement.

I don't want to revisit LoST dereference of LbyR.  As we said, the LoST
server may be operated by lots of different entities and I don't want to
have to tie them into an authorization mechanism for dereferencing.  In
fact, I really want to make sure that operationally, whether it's the
endpoint, the access network or the VSP that is doing the LoST dip, I
want it to work everywhere.  

I do think having country code visible is a good thing.  I have two
reasons (validation and disputed territory).  You add a third.  I think
we need to make sure country code is visible.  That is a change.

It's true that the access network has more of a responsibility to
support emergency calling in next generation networks.  The VSP (or its
equivalent, for example, an IM service provider), has to have a very low
level of responsibility, namely, routing a call to the PSAP.  We want
that to be true primarily because of the difficulty in regulating
services providers across the Internet.  Access networks, after all, are
always local.  IM service providers and VSPs are not necessarily local,
but we want them to support emergency calling anyway.  We need to make
it as lightweight on them.

I recall asking a founder of Skype if the access network supplied
location, the route database was publically available on the Internet,
and the PSAP accepted SIP calls from the Internet if free Skype service
would support emergency calling.  His answer was very illustrative: "why
not?"  Not just "probably yes", not even just "yes" but "why not?".
That's the reaction we want.

I think most access networks will provide location for emergency calling
for the reason listed.  They really do think it is part of their
responsibility as a common carrier.  Local networks will support the
local emergency services.  That is as it should be.  The problem is that
we need ALL access networks to support local emergency calling.  The
"ALL" inevitably implies regulation.  In the IETF, we don't have to deal
with those issues, but our architecture is dependent on ALL.

Brian 

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Monday, April 16, 2007 1:01 PM
> To: Rosen, Brian; Henning Schulzrinne
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
do
> endpointcentric LCP without giving away the store
> 
> Absolutely - agreed. Now I've finally reached the top of the thread.
> Here's my perspective:
> 
> * Devices and VSPs should be assumed to have *no* knowledge of the
> emergency jurisdiction or the access networks - that includes their
> preferred form of location presentation, whether signing is required,
> and what rights/rules exist if dereferencing is to occur.
> 
> * The access network should be assumed to know what the local
> jurisdiction expects, is able to do, and of course what the access
> provider wants to do viz restricting availability of the location
> information.
> 
> The corollary is that most of the responsibility for ensuring
> interoperability of emergency services at the local level lies with
the
> access provider and the local emergency services provider(s). The
device
> needs to know how to find the LIS, ask for location suitable for
> emergency use, get it to the LoST server and initiate the call with
the
> location information included.
> 
> While the LoST server could be part of the access, it certainly
doesn't
> have to be. There's nothing in LoST that makes the access provider the
> most suitable entity to administer the server. I also agree that
> conflating the emergency routing service with the location service is
> unnecessary and would only reduce flexibility for different
> jurisdictions. So let's try to avoid turning HELD into anything more
> than a location protocol. (Somebody mentioned that adding
configuration
> information to a location protocol would be counter-productive. I
> heartily agree, and think the converse applies. Sorry - I couldn't
> resist that).
> 
> Implied in what I said above is the need for the LCP to support an
> explicit request for the "emergency form" of location. HELD does have
> that currently but in discussions with Martin T and James W, we think
> this needs beefing up due to the "richness of the permutations" that
can
> be expected in different jurisdictions.
> 
> There are two other things that I would really appreciate being
> considered and discussed:
> 
> * Re-evaluating the support of LbyR in the LoST query (since the
device
> cannot assume the form in which the access will provide location).
> 
> * Defining a method (BCP or otherwise) by which a VSP can determine at
a
> high level of granularity (I'd be happy with country code) what
> jurisdiction the call is coming from. This is purely to support i2
type
> architectures where it is the VSP responsibility to identify the
correct
> VPC. Without some kind of jurisdiction-indication, particularly when
> location is provided as a reference, it will be difficult to support
> global roaming for subscribers. As above, a VSP cannot be assumed to
> have the right to do a dereference - the LIS may be in a completely
> different country. For example, can a BCP for reference construction
> include this consideration?
> 
> Cheers,
> Martin
> 
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, 17 April 2007 2:14 AM
> To: Dawson, Martin; Henning Schulzrinne
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
do
> endpointcentric LCP without giving away the store
> 
> 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.
> 
> Brian
> 
> > -----Original Message-----
> > From: Dawson, Martin [mailto:[email-masked]]
> > Sent: Monday, April 16, 2007 12:10 PM
> > To: Henning Schulzrinne; Rosen, Brian
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> do
> > endpointcentric LCP without giving away the store
> >
> > All very true I think. Providing location, in my view, is likely to
go
> > through the usual stages:
> >
> > * Pay to play
> > * Free as a competitive differentiator
> > * Lowest common denominator and assumed as part of the access
> >
> > I think the first phase is likely to prove quite short, to
> non-existent,
> > because of the cost of putting the billing overlay in.
> >
> > Telephone companies didn't go into business to provide connectivity
to
> > emergency services but, eventually, they did it because it's a
social
> > service and society enforced the obligation - emergency calling,
> > including location, became an assumed part of the bundle.
> >
> > Similarly, the physics of the situation dictates it's the providers
of
> > broadband Internet access who can work out location (it's not like
> it's
> > a business conspiracy) and, eventually, this will become an assumed
> part
> > of the access bundle.
> >
> > In cellular networks, the location request associated with
initiating
> an
> > emergency call is called a "network initiated" request because the
> > mobile switching center makes the request to the location server.
> > However, most networks also support a form of request called
> > "mobile-originated". It's quite likely that any suitably capable
> handset
> > can request location, unhindered, from those mobile networks. That's
> > control plane - but SUPL permits SET-initated requests as well.
> >
> > Providing location in cellular networks is probably the most network
> > resource intensive form of this service. The precedent is in,
really,
> > that users will be able to get their location for free.
> >
> > The business strategists that you refer to still need to go through
> > their own processes and come to their own conclusions but I don't
> think
> > you'll be suffering stock option envy on this count Henning.
> >
> > Cheers,
> > Martin
> >
> >
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Sunday, 15 April 2007 12:52 AM
> > To: Rosen, Brian
> > Cc: [email-masked]; [email-masked]
> > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
> > endpointcentric LCP without giving away the store
> >
> > [This is partially an editorial, but I'll get to solutions in the
> > next message...]
> >
> > My prediction is that the dream of untold riches to be mined from
> > location information is largely just that.
> >
> > In particular, I believe that the value of non-emergency location
> > information for stationary devices in a residential setting is
pretty
> > close to zero. After all, users already know their home address and
> > for pizza delivery and similar tasks, it doesn't much matter whether
> > the address validates. Users will fix their address after the first
> > cold pizza arrives.
> >
> > As a practical matter, monetizing this information is going to be
> > very difficult, particularly in European Union countries with strong
> > privacy laws. A VSP is very unlikely to pay for location
information,
> > as it has no direct need for it. The local pizza parlor might find
> > the information to be of interest, but the logistics are pretty
> > daunting. Since you can't easily do per-use approval, as you can do
> > with end system location, the pizza parlor would have to contact the
> > various access providers and negotiate an arrangement. In addition,
> > and most onerously, the pizza parlor would probably need to get
> > individual approval from each potential customer to release this
> > information to them. As a customer, why would I agree to release
> > location information to every business, known and unknown, for
> > purposes unknown? This can be fixed by uploading GEOPRIV policy to
> > the access provider, but this requires heavy-duty machinery, as
> > customers have to figure out which domains to include in that list.
> > The likelihood that users will remember to add the pizza parlor's
> > domain name to that list before calling for delivery is pretty slim.
> > For a second delivery, the restaurant already has the correct and
> > verified address, so it has limited additional value.
> >
> > Let's assume for a moment that stationary-device location is indeed
> > tremendously valuable. If so, we'll very quickly get a budding
> > entrepreneur that will get the location from the access provider and
> > then sell it, once, to the customer, for free use henceforth until
> > the customer changes ISPs. Heck, depending on pricing, the customer
> > might do it himself. I'd look forward to the having the access
> > provider sue this enterprise for handing a customer their own street
> > address. ("Yes, your honor, we don't allow this company to tell our
> > customer where they live.")
> >
> > Maybe Domino's will advertise "Get your free serving of location
with
> > our extra large pepperoni pizza!".
> >
> > Thus, this whole hide-location-from-customer thing has the distinct
> > feeling of cutting off your nose to spite your face or, more to the
> > topic, of "I can't make VoIP pay for me, so I'm going to make it
> > difficult for everybody else to offer services, too".
> >
> > Location information is obviously valuable for mobile users, but I
> > suspect that the consequence of making it difficult to get will
> > simply increase the use of (unassisted) GPS and SkyHook, or
BlueTooth
> > on in-car navigation devices. (As navigation functionality gets
> > integrated into mobile phones, this has to work even when there is
no
> > cell coverage.)
> >
> > While I doubt that this argument will suddenly convince the
brilliant
> > strategists in telecom companies, at least I'll have a convenient
> > place to point to for an "I told you so" five years from now, or
> > maybe a good place to be proven wrong while others cash in their
> > stock options.
> >
> > Henning
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
>
------------------------------------------------------------------------
> --
> > ----------------------
> > 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]

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 13:35:05 -0400

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
>
> 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
> On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote:
>
>> Right.  Good summary.
>>
> 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
>
> ---------------------------------------------------------------------- 
> --------------------------
> ---------------------------------------------------------------------- 
> --------------------------
> [mf2]
>