Subject: [Ecrit] simplified R5?

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Jul 2005 12:50:53 -0700

I'm beginning to strongly suspect that part of R5 belongs in the implementation
and deployment docs, rather than as a protocol requirement.  Going through
Henning's scenario (in which the fresh data is first checked, but the
local copy is available), I realized that we could run that exact scenario
in reverse--the local copy is not available, but the "parent" copy is
available by some onerous network path.   Checking the local copy first
might be sensible in some network topologies, and preferring one over
the other seems problematic.

That led me to a far simpler protocol requirement--the the protocol must 
be able to support topologically distinct redundant servers.  Whether these 
get updated via pull-based caching, a replication process, or the seasonal 
migration of avian carriers doesn't really enter into what the client needs to do---
check a second identified server if the first one craps out.  For the current
work of ECRIT, this seems in scope, where some elements of the other
discussion look out of scope.

Also, I really fear that R5 as discussed (though possibly not as written)
implies that the infrastructure for mapping be maintained by the access
provider, even though the voice services provider 1) is responsible for
delivering the call, 2) must be up and available to do so, and 3) has
a business reason to do so (the other is an "unfunded mandate" that
regulation might achieve but the market will resist).  That may be
a common thing, but I believe we have to support scenarios where
it isn't the way the deployment works.

As a proposal, I'd like to suggest we scrap R5 as written, replace it with 
"the protocol must support topologically distinct redundant servers", and 
discuss the good ways of achieving that in the deployment doc.

			regards,
				Ted Hardie

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Jul 2005 21:53:01 -0400

> the other seems problematic.

My "algorithm" was just a short-hand, albeit ill-formulated, for a 
standard DNS-like caching algorithm, with the immediate query 
representing a TTL of 0.

The only real difference to DNS or web caching is that these don't 
typically deal with the fact of connectivity loss and cache expiration, 
as far as I know. A system suitable for emergencies has to consider that 
issue.

> discussion look out of scope.

Topologically distinct is clearly necessary, but not good enough. Unlike 
in a normal network scenario, where large-scale failures are rare, for 
emergency calling, you can easily imagine that only relatively local 
connectivity remains.

Having servers in CA and MA doesn't help much if the local cable company 
in NY is still up (and connected to the local PSAP), but has lost 
upstream connectivity to the rest of the Internet (or that connectivity 
is severely overloaded).

I want to be able to deploy reliable systems that are standards-based, 
not just rely on some background magic to somehow make this happen.

> it isn't the way the deployment works.

As I noted earlier, based on your note, the network path includes both 
the call signaling and the media path. Thus, the MSP could just as 
easily host this server, without endangering fate sharing (assuming that 
it requires an outbound proxy).

In addition, the VSP does *not* have to be "up and available" to serve 
the call. At least in a SIP environment, if the end system or an 
"emergency" proxy in the local network does ECRIT lookup, the end system 
can directly connect to the PSAP, without the MSP being involved at all. 
Given that it is common mandate that cell phones can place 911 calls 
without being active subscribers to a service, this may occur with some 
frequency.

> discuss the good ways of achieving that in the deployment doc.

For the reasons noted, I think that shortchanges an important design 
consideration.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Jul 2005 15:00:34 -0700

At 9:53 PM -0400 7/1/05, Henning Schulzrinne wrote:
>>
>>That led me to a far simpler protocol requirement--the the protocol must be able to support topologically distinct redundant servers.  Whether these get updated via pull-based caching, a replication process, or the seasonal migration of avian carriers doesn't really enter into what the client needs to do---
>Topologically distinct is clearly necessary, but not good enough. Unlike in a normal network scenario, where large-scale failures are rare, for emergency calling, you can easily imagine that only relatively local connectivity remains.

The point I was making is that topologically distinct allows you to deal with
both local failures and large-scale failure.  To flesh this out:  you have power
and network connectivity to a DC-powered DSLAM where the power surge in the
CO after your emergency fried all the AC-powered servers.  Having the topologically
distinct master server available means you can still get the mapping done to
call for help.  From the client's perspective, what it needs is a list (probably
an ordered list) of servers it can use.  From a deployment perspective, what
we need is sensible distribution of the servers--and that can include many
different kinds of replication, including "local cache of master server", but
this is deployment advice, not a protocol requirement. 

><snip>
>As I noted earlier, based on your note, the network path includes both the call signaling and the media path. Thus, the MSP could just as easily host this server, without endangering fate sharing (assuming that it requires an outbound proxy).

Sorry, assuming what require an outbound proxy?  I think I lost your point here.

>In addition, the VSP does *not* have to be "up and available" to serve the call. At least in a SIP environment, if the end system or an "emergency" proxy in the local network does ECRIT lookup, the end system can directly connect to the PSAP, without the MSP being involved at all. Given that it is common mandate that cell phones can place 911 calls without being active subscribers to a service, this may occur with some frequency.

I think you misunderstood me.  I'm saying if we *require* the access provider to
handle the infrastructure, it is an unfunded mandate; we can certainly design
so that they *may* provide it, but we also out to take into account deployments
where they do not and someone like the VSP does.  But I don't think we can
handle requirements where the access provider isn't available--if they're not
up, the bits don't flow.

Again, I think the protocol requirement here is to be able to handle multiple,
topologically distinct servers.  Describing where it is sensible to keep these
multiple copies is useful stuff, but it is not a protocol requirement.
			regards,
				Ted Hardie

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Jul 2005 10:41:35 -0400

Ted Hardie wrote:

> The point I was making is that topologically distinct allows you to
> deal with both local failures and large-scale failure.  To flesh this
> out:  you have power and network connectivity to a DC-powered DSLAM
> where the power surge in the CO after your emergency fried all the
> AC-powered servers.  Having the topologically distinct master server
> available means you can still get the mapping done to call for help.
> From the client's perspective, what it needs is a list (probably an
> ordered list) of servers it can use.  From a deployment perspective,
> what we need is sensible distribution of the servers--and that can
> include many different kinds of replication, including "local cache
> of master server", but this is deployment advice, not a protocol
> requirement.

We clearly need topologically distinct, but 'topologically distinct' 
doesn't address the locality constraint. Let me try to give an example 
of a system that satisfies topologically distinct, but would not work 
well for emergency mapping:

Assume the caller placing the 911 call is physically located in Detroit; 
presumably, the PSAP serving her is in Detroit as well.

The ECRIT service provider is in DC, with redundant servers in SF and 
NY. A disaster strikes and wide-area network connectivity is disrupted. 
In other words, our caller in Detroit can't get to SF or NY, but can 
ping the PSAP and route a SIP call there (if she knew where it was).

This is not a common scenario for normal Internet service, as local 
connectivity only isn't particularly useful. (Almost all web sites 
wouldn't be reachable if there's no wide-area connectivity, even if DNS 
continues to function.) However, emergency calling is inherently local - 
most of the interesting, time-critical communication will take place 
between entities located within a few miles of each other. [There are 
exceptions in some sparsely populated states, with state-wide PSAPs, but 
given the number of 6,000 PSAPs in the US, this is pretty close.]

As an aside, I suspect that in the future, PSAPs will have direct IP 
connectivity into the major local ISPs such as the DSL and cable 
providers, as that avoids having to rely on possibly remote exchange 
points or peering.

In summary: redundant, diverse server setups are necessary, but not 
sufficient.

> 
> 
>> <snip> As I noted earlier, based on your note, the network path
>> includes both the call signaling and the media path. Thus, the MSP
>> could just as easily host this server, without endangering fate
>> sharing (assuming that it requires an outbound proxy).
> 
> 

The point is that both the ISP and the MSP could operate a caching ECRIT 
server. There are two cases:

(1) The MSP allows direct connections to any SIP address without going 
through an outbound proxy. (Or there is no MSP as such - another common 
case.) In that case, the caller could either use the ISPs ECRIT service 
or some other service.

(2) The MSP requires use of its outbound proxy server for all calls. In 
that case, it would be desirable for the lookup function to reside there 
as well, to limit exposure to long-distance failures.

We don't know how ECRIT will be deployed, but the protocol machinery 
needs to support highly robust deployment architectures, even if some 
will choose to run a single server from a trailer park in Florida using 
IP-over-barbed-wire-fences.

> I think you misunderstood me.  I'm saying if we *require* the access
> provider to handle the infrastructure, it is an unfunded mandate; we
> can certainly design so that they *may* provide it, but we also out
> to take into account deployments where they do not and someone like
> the VSP does.  But I don't think we can handle requirements where the
> access provider isn't available--if they're not up, the bits don't
> flow.

I don't think anything I said requires that the access provider runs 
this service. I don't want to get into unfunded mandates - if this is 
cheap enough to run, ISPs will offer it just like they offer DNS today, 
even though they could clearly tell their customers to get their DNS 
service elsewhere. [In many cases, access providers will also offer VoIP 
service in any event.]

> 
> Again, I think the protocol requirement here is to be able to handle
> multiple, topologically distinct servers.  Describing where it is
> sensible to keep these multiple copies is useful stuff, but it is not
> a protocol requirement. regards, Ted Hardie

The problem is that this is not sufficient. I think the requirement that 
got lost in the discussion thread is the ability to run a *caching* copy 
of the database. That allows lots and lots of such servers, including 
those located very close to the subscribers.

Thus, I think the location discussion is a bit besides the point; it 
simply motivates the need for the equivalent of non-authoritative 
servers, to use DNS terminology.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Mon, 11 Jul 2005 10:22:26 -0700

At 10:41 AM -0400 7/9/05, Henning Schulzrinne wrote:
>T
>
>We clearly need topologically distinct, but 'topologically distinct' doesn't address the locality constraint. Let me try to give an example of a system that satisfies topologically distinct, but would not work well for emergency mapping:
>
>Assume the caller placing the 911 call is physically located in Detroit; presumably, the PSAP serving her is in Detroit as well.
>
>The ECRIT service provider is in DC, with redundant servers in SF and NY. A disaster strikes and wide-area network connectivity is disrupted. In other words, our caller in Detroit can't get to SF or NY, but can ping the PSAP and route a SIP call there (if she knew where it was).
>
>This is not a common scenario for normal Internet service, as local connectivity only isn't particularly useful. (Almost all web sites wouldn't be reachable if there's no wide-area connectivity, even if DNS continues to function.) However, emergency calling is inherently local - most of the interesting, time-critical communication will take place between entities located within a few miles of each other. [There are exceptions in some sparsely populated states, with state-wide PSAPs, but given the number of 6,000 PSAPs in the US, this is pretty close.]
>
>As an aside, I suspect that in the future, PSAPs will have direct IP connectivity into the major local ISPs such as the DSL and cable providers, as that avoids having to rely on possibly remote exchange points or peering.

I don't disagree with the scenario at all.  But the locality of the server doesn't
change the protocol mechanism.  The system needs to provide a set of weighted
or ordered alternate servers for this mechanism so that someone can try
to reach the alternates in the emergency.  The system trying to make the
emergency contact shouldn't need to understand either the topology or
the locality of the servers it's trying to reach--it's just working off an
annotated list.

So I think your scenario would be a very useful addition to a deployment doc,
explaining why you want both topological distinct servers and locality, but
I don't see a *protocol* requirement here other than "support topologically
distinct servers" and "provide a mechanism for preference among available
servers (e.g. weighting or ordering)".

>
>The problem is that this is not sufficient. I think the requirement that got lost in the discussion thread is the ability to run a *caching* copy of the database. That allows lots and lots of such servers, including those located very close to the subscribers.
>
>Thus, I think the location discussion is a bit besides the point; it simply motivates the need for the equivalent of non-authoritative servers, to use DNS terminology.
>

And I think the *caching* aspect is one where we do have disagreements.  Caching
is one data replication technology, but it is far from the only one and it isn't clear
that its characteristics are a good match for this problem space.  If you do pull-based
caching (a la the DNS or HTTP caching proxies), you have to worry about
cache freshness, appropriate cache size, and other aspects of the algorithm
for cache ejection.  If you are not doing demand-based cache population, you may also have to worry about how the traffic for refreshing cache entries competes with the
traffic for emergencies. 

If you are thinking of the DNS, you should note that not only did demand-based
cache population not get used for "slave" authoritative servers, there are at least
two common technologies for populating those--AXFR and rsynch, with backend
SQL servers' replication a likely third. 

Before going down the caching road to far, to what extent do you perceive the need
for a *local* server to combine data from multiple sources, and what numbers of
sources are we talking about here?  Are we expecting the local servers to have any
trust relationships with the authoritative sources? 
			regards,
				Ted Hardie

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2005 21:59:02 -0400

Ted Hardie wrote:

> I don't disagree with the scenario at all.  But the locality of the
> server doesn't change the protocol mechanism.  The system needs to
> provide a set of weighted or ordered alternate servers for this
> mechanism so that someone can try to reach the alternates in the
> emergency.  The system trying to make the emergency contact shouldn't
> need to understand either the topology or the locality of the servers
> it's trying to reach--it's just working off an annotated list.

Indirectly, it does affect the operation. There are likely to be 
thousands of ISPs, MSPs and MSP-like organizations (i.e., organizations 
that provide VoIP services to their users, but don't sell the service to 
the public, such as most mid- to large-size enterprises and 
institutions). Reliability is increased significantly if these 
organizations can provide service locally, even if they are not at all 
authoritative for the data.

This probably got lost in the discussion before, since I kind of assumed 
this, but I get the feeling that some participants in this discussion 
have a very different deployment model, namely one of a paid service 
more akin to a very reliable phone directory that you contact after 
obtaining a contract. ("Hi, directory assistance, what's the number for 
the police department in Smithville?").

Thus, maybe the more important consideration is not as much the precise 
placement, but the ability to place lots of mapping servers close to the 
user, operated by a variety of entities that may only have a loose 
association with the source of the data. (This describes, at a high 
level, the DNS model, I think.)

I don't know if deployments will develop in that direction, but I'd 
rather not prejudge business models and rule out such distributed 
arrangements by limiting protocol capabilities. Some people who have 
been involved in the 911 stuff for a while have seen what logically 
centralized directories do to competition and pricing.

> 
> So I think your scenario would be a very useful addition to a
> deployment doc, explaining why you want both topological distinct
> servers and locality, but I don't see a *protocol* requirement here
> other than "support topologically distinct servers" and "provide a
> mechanism for preference among available servers (e.g. weighting or
> ordering)".

See above - it's more than weighting or physical distribution. Indeed, 
in the model of highly distributed servers, there is no central place to 
go ask  for weights, lists of servers or anything else.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 11 Jul 2005 22:10:57 -0400

On Jul 11, 2005, at 9:59 PM, Henning Schulzrinne wrote:

> organizations that provide VoIP services to their users, but don't  
> sell the service to the public, such as most mid- to large-size  
> enterprises and institutions

Let me see.  My options are to buy two servers, each with dual power  
supplies and hot-swappable RAID, and the on-going expense of an admin  
to keep the boxes up, OR gateway 911 calls to the PSTN for free.   
Decisions.  Decisions.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2005 22:17:04 -0400

> to keep the boxes up, OR gateway 911 calls to the PSTN for free.   

Thanks for raising the level of discussion.

Except that gatewaying to the PSTN for 911 is not a viable option if my 
customers live outside the service area of a single PSAP. Think any 
service provider with a national footprint (Skype, Vonage).

The current option for MSPs with regional coverage is to go provide or 
buy gateway access to about 2,000 selective routers in the US, while 
still not offering number portability, mobility and other services.

I'll ignore the fact that there won't be a PSTN service as such at some 
point in the future, hopefully while the ECRIT protocol is still in use.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2005 22:37:27 -0400

Ted Hardie wrote:

> And I think the *caching* aspect is one where we do have
> disagreements.  Caching is one data replication technology, but it is
> far from the only one and it isn't clear that its characteristics are
> a good match for this problem space.  If you do pull-based caching (a
> la the DNS or HTTP caching proxies), you have to worry about cache
> freshness, appropriate cache size, and other aspects of the algorithm
>  for cache ejection.  If you are not doing demand-based cache
> population, you may also have to worry about how the traffic for
> refreshing cache entries competes with the traffic for emergencies.

Sure, but as I indicated in earlier iterations of this discussions, 
these problems are all likely to be significantly easier than for either 
HTTP or DNS, even under very extreme assumptions. (The number of data 
elements is much smaller, there is much more locality and relatively 
little change.) Thus, I believe that very good cache hit ratios can be 
achieved.

I had provided a number of ways that this could be made to work earlier, 
but this isn't really the time to go through those.

Clearly, these mechanisms need to be designed, but do you see a 
fundamental problem that prevents the use of caching in this application?

At the requirement level, caching isn't really the issue, but the 
distributed administration.

> 
> If you are thinking of the DNS, you should note that not only did
> demand-based cache population not get used for "slave" authoritative
> servers, there are at least two common technologies for populating
> those--AXFR and rsynch, with backend SQL servers' replication a
> likely third.

There are two separate problems here that are getting somewhat 
commingled: Synchronization of authoritative servers and local caching. 
These are distinct problems, with likely somewhat different solutions. 
(Synchronization needs to ensure that the two data stores are exactly 
the same; caching only optimizes retrievals and can work probabilistically.)

Just because some people use rsynch and SQL server replication doesn't 
mean that having DNS offer AXFR was a bad idea or shouldn't have been 
done. There will always be locally optimal mechanisms that aren't 
standardized, but we need to provide protocol mechanisms that work well 
in lots of circumstances, without a "and to really make this reliable, 
you have to agree on some proprietary mechanism since we couldn't be 
bothered to specify the hard stuff".

I certainly would never claim that we would prescribe how 
synchronization should always be done, but there are strong advantages 
to having a minimal level of interoperability between organizations that 
do things, for example, on a mutual-aid basis.

> 
> Before going down the caching road to far, to what extent do you
> perceive the need for a *local* server to combine data from multiple
> sources, and what numbers of sources are we talking about here?  Are
> we expecting the local servers to have any trust relationships with
> the authoritative sources? regards, Ted Hardie

Back-of-an-envelope calculation: There are 1.2 million companies with 50 
to 250 workers 
[http://seattlepi.nwsource.com/business/231746_msftsales08.html, 
courtesy of random googling]. Each one is likely to eventually have a 
VoIP system if they have other network infrastructure. It should be 
possible that each one of these runs a local ECRIT server, as they are 
likely to run a DNS or mail server. Clearly, there are thousands of 
ISPs, almost all of whom are likely to either offer or resell VoIP service.

The number of sources can vary. One reasonable deployment model is that 
you'd have each PSAP advertise its own coverage region, making for about 
6,000 sources in the US. That number seems unlikely, but is probably a 
useful upper bound.

Obviously, each of the midsize companies would mostly care about 
information for its own geographic area (say, the 20 restaurants that it 
operates as a franchisee in a metro area), not the whole US. It might 
possibly care about the home locations of its workers, as they might VPN 
in from home. The number of entries in any local cache would be small 
(maybe a few hundred for the companies I mentioned above).

In a distributed model, I would expect the servers to have some kind of 
trust relationship with the authoritative servers, but this could be 
something simple, such as some kind of capability cert in TLS ("Hi, I'm 
a government-certified PSAP advertiser"). There are other alternatives, 
e.g., where trust is established on a per-data item level, but I'd 
rather not engineer a solution at this point since this tends to just 
lead to micro-critiques of the solution rather than requirement 
discussion. As far as I can tell, this issue is also relatively 
independent of the fact that there'd be a caching hierarchy.

But, going back to my earlier question, maybe the model in some 
discussant's mind is that a single company runs the server farm, say, on 
a country-wide basis, and users would only connect to one of those 
servers. (Or, similarly, a small number of such companies that users 
would contract with and that use some non-standardized means to populate 
their own complete mapping database from PSAP information.)

It might be helpful to bring out those assumptions, since they may color 
our design assumptions and what one might consider reasonable 
requirements. This might be more illuminating than costing RAID arrays.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 11 Jul 2005 22:49:47 -0400

> Thanks for raising the level of discussion.

Oh, I think its a fair question.  In all this, you have outlined some  
pretty serious requirements with some pretty serious liabilities  
should something go wrong... all of this being placed upon small and  
medium sized businesses wishing to take advantage of VoIP.

> Except that gatewaying to the PSTN for 911 is not a viable option  
> if my customers live outside the service area of a single PSAP.  
> Think any service provider with a national footprint (Skype, Vonage).

You've changed the subject... but highlighted one of the concerns Ted  
mentioned.  Do Skype and Vonage run the layer 2 network, the DHCP  
servers, and the DNS servers?  I'm sure the access providers are  
happy to sell me access so I can use Vonage, but I'm sure they will  
be unhappy to take on the liability you have outlined if they aren't  
receiving any compensation.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2005 23:00:12 -0400

Andrew,

I don't think discussing business models is particularly productive 
here. Neither of us knows that the deployment architecture will look 
like, but I don't want to lock us into one model, even if there are 
vendors participating in the working group who might be more than happy 
to take the load and liability of the ISPs or MSPs shoulders, for a fee.

As to your second remark, this has nothing to do with the choices ISPs 
make. The same discussion holds if MSPs or businesses want to run ECRIT 
services. Besides, the distinction between ISP and VSP will be 
organizationally moot, in that most ISPs are likely to also offer VSP 
services unless prohibited by a regulator. Thus, the only likely 
question is whether they'll restrict the ECRIT service to their own VSP 
customers and whether regulators will allow that.

But I'm not sure that crystal-ball gazing is particularly productive 
here as, short of time travel, we won't be able to conclude this discussion.

The pertinent protocol discussion is whether the ECRIT protocol design 
needs to support an organizationally distributed model, even if we can't 
predict for sure that this will be the deployment model. If we don't 
engineer for this, we have decided the deployment and business model, 
just like the limitations of the existing MSAG and ALI technology have 
decided the business model for CLECs and I1 offerings in the United States.

Henning

Andrew Newton wrote:
> pretty serious requirements with some pretty serious liabilities  should 
> something go wrong... all of this being placed upon small and  medium 
> sized businesses wishing to take advantage of VoIP.
> 
>> Except that gatewaying to the PSTN for 911 is not a viable option  if 
>> my customers live outside the service area of a single PSAP.  Think 
>> any service provider with a national footprint (Skype, Vonage).
> 
> 
> servers, and the DNS servers?  I'm sure the access providers are  happy 
> to sell me access so I can use Vonage, but I'm sure they will  be 
> unhappy to take on the liability you have outlined if they aren't

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Jul 2005 00:07:15 -0400

Henning,

Like you, I do not think it is productive to discuss business  
models.  Nor do I think either of us knows what the deployment  
architecture will look like.  And like you, I do not want to lock us  
into one model, especially one dictated by semantics in a protocol  
that cannot possibly be designed without knowledge of the deployed  
architecture.

I have simply asked clarifying questions regarding caches and  
database replication that you have asserted are part of the R5 item  
titled "Minimum Connectivity".  If such a requirement is to be given,  
its meaning must be well understood.  Yet the assertions given  
regarding this requirement are not well understood.

The pertinent protocol discussion is whether or not the ECRIT  
protocol needs to have semantics for database replication in a query  
that uses location as a parameter in order to acquire a URI.  As you  
have stated, we cannot predict the deployment model.  Therefore, we  
should not burden this query with any semantics for database  
replication as they may not match the model that will be deployed.   
This is especially true given that there is no certainty against  
replication via other means.

-andy

On Jul 11, 2005, at 11:00 PM, Henning Schulzrinne wrote:

> here. Neither of us knows that the deployment architecture will  
> look like, but I don't want to lock us into one model, even if  
> there are vendors participating in the working group who might be  
> more than happy to take the load and liability of the ISPs or MSPs  
> shoulders, for a fee.
>
> As to your second remark, this has nothing to do with the choices  
> ISPs make. The same discussion holds if MSPs or businesses want to  
> run ECRIT services. Besides, the distinction between ISP and VSP  
> will be organizationally moot, in that most ISPs are likely to also  
> offer VSP services unless prohibited by a regulator. Thus, the only  
> likely question is whether they'll restrict the ECRIT service to  
> their own VSP customers and whether regulators will allow that.
>
> But I'm not sure that crystal-ball gazing is particularly  
> productive here as, short of time travel, we won't be able to  
> conclude this discussion.
>
> The pertinent protocol discussion is whether the ECRIT protocol  
> design needs to support an organizationally distributed model, even  
> if we can't predict for sure that this will be the deployment  
> model. If we don't engineer for this, we have decided the  
> deployment and business model, just like the limitations of the  
> existing MSAG and ALI technology have decided the business model  
> for CLECs and I1 offerings in the United States.
>
> Henning
>
> Andrew Newton wrote:
>
>> Oh, I think its a fair question.  In all this, you have outlined  
>> some  pretty serious requirements with some pretty serious  
>> liabilities  should something go wrong... all of this being placed  
>> upon small and  medium sized businesses wishing to take advantage  
>> of VoIP.
>>
>>> Except that gatewaying to the PSTN for 911 is not a viable  
>>> option  if my customers live outside the service area of a single  
>>> PSAP.  Think any service provider with a national footprint  
>>> (Skype, Vonage).
>>>
>> You've changed the subject... but highlighted one of the concerns  
>> Ted  mentioned.  Do Skype and Vonage run the layer 2 network, the  
>> DHCP  servers, and the DNS servers?  I'm sure the access providers  
>> are  happy to sell me access so I can use Vonage, but I'm sure  
>> they will  be unhappy to take on the liability you have outlined  
>> if they aren't  receiving any compensation.
>> -andy
>>
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 12 Jul 2005 08:21:28 -0400

Businesses that have a "single" IP-PBX and deploy teleworkers with phones
that are served by that single system, or who have multiple sites that are
served from one gateway for calls to the PSTN have the problem that they
have to direct 9-1-1 calls somewhere other than where there PSTN connection
could get them.

Their current liability is pretty large if they deploy such systems, because
they don't work, and they know they don't work.

A similar argument, with other implications, occurs with a road warrior,
where the call routing element is half a world away.  

I think Henning is quite right; there must be mechanisms to provide mapping
information where there are no prior arrangements -- the source of the
authoritative mapping information has no relationship with the call routing
element, and these must work when there are large disruptions to the
Internet.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Newton
Sent: Monday, July 11, 2005 10:50 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] simplified R5?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Jul 2005 21:52:04 -0400

Andrew,

I'm afraid I don't follow the logic.

Your restriction only allows one set of business model, thus restricting 
the ability to support others, including those where equivalent ones are 
well-developed in semantically related contexts.

Any particular protocol use can easily drop whatever features are 
unnecessary for their particular deployment model. If you omit certain 
crucial features, however, you have prevented these architectures from 
existing. I have no objection to you believing your particular network 
architecture does not need replication (or caching); I do have a problem 
you wanting to prevent others from designing what they believe is a 
reasonably complete protocol that can be inherently reliable by design, 
rather than non-standard external conventions that essentially prevent 
loosely-coupled associations. By analogy: We don't say that since there 
are many possible security architectures, crypto algorithms and the like 
and since not all implementations will need or want crypto, that we 
don't specify a minimum set of security mechanisms.

Henning

Andrew Newton wrote:
> Henning,
> 
> Like you, I do not think it is productive to discuss business  models.  
> Nor do I think either of us knows what the deployment  architecture will 
> look like.  And like you, I do not want to lock us  into one model, 
> especially one dictated by semantics in a protocol  that cannot possibly 
> be designed without knowledge of the deployed  architecture.
> 
> I have simply asked clarifying questions regarding caches and  database 
> replication that you have asserted are part of the R5 item  titled 
> "Minimum Connectivity".  If such a requirement is to be given,  its 
> meaning must be well understood.  Yet the assertions given  regarding 
> this requirement are not well understood.
> 
> The pertinent protocol discussion is whether or not the ECRIT  protocol 
> needs to have semantics for database replication in a query  that uses 
> location as a parameter in order to acquire a URI.  As you  have stated, 
> we cannot predict the deployment model.  Therefore, we  should not 
> burden this query with any semantics for database  replication as they 
> may not match the model that will be deployed.   This is especially true 
> given that there is no certainty against  replication via other means.
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Jul 2005 23:16:59 -0400

On Jul 12, 2005, at 9:52 PM, Henning Schulzrinne wrote:

> I have no objection to you believing your particular network  
> architecture does not need replication (or caching)

Henning,

You have misunderstood what I have stated.  It isn't that I do not  
see a need for database replication.  It is that I do not see a need  
for database replication in the protocol spoken by a client  
attempting to do location-to-URI mapping.

Additionally, it would appear that you do believe there will be a  
need for database replication.  That is fine.  And that is what your  
requirement should speak of, but it does not.

-andy