Subject: Re: [Ecrit] R5

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Jul 2005 00:29:21 -0400

On Jun 30, 2005, at 11:09 PM, Henning Schulzrinne wrote:
> Thus, even if every Verizon POP in the US had cached the complete  
> address table for the US, storage is going to be a trivial expense.

I suppose things like indexes and all those nice little data  
management bits come from free on the disks you buy?  I have a  
SleepyCat database of 4 million IPs sitting on my disk.  Using your  
guidelines, the database size should only be 20 meg ( (4 bytes for  
IPv4 key + 1 byte of value) * 4m ).  Yet, it appears to be 448 meg.

There is more to data management than the size of the record.

> Clearly, caches have timeouts and need to be updated, but very  
> slowly, since address-to-PSAP mappings don't change very frequently.

This is the real problem.  How slowly?  How often is an emergency  
call made from every address, or even from most addresses?  If the  
TTL is set to 5 years, that means changes in the mapping must wait 5  
years to fully propagate.  If the TTL is 6 months, won't most entries  
expire out of the cache?

>> At the interim meeting, Marc told me of a state where they did  
>> not  want the information to be widely distributed below the state  
>> level.
>>
>
> I'm sorry to say that the basic design of ECRIT makes hiding such  
> information difficult, caching or not. Since doing the lookup does  
> not require to actually place a 911 call, I can easily do mappings  
> from any address I care to, at my leisure. I don't have to test all  
> addresses, just a few to get a very good idea whether, say, my  
> local PSAP serves the county or just one community.

You are right for civic addresses, but for coordinates the guessing  
game could be quite lengthy.

But you've assumed a system where the client runs the actual  
geographic mapping algorithm and not the server.
If that is how it is to be, then I'm fine with that... so long as  
everybody knows that is a requirement (in other words, it needs to be  
explicit in the requirements document).

-andy

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

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 1 Jul 2005 08:24:59 -0400

--snip--
> 
> > 
> > At the interim meeting, Marc told me of a state where they 
> did not  want 
> > the information to be widely distributed below the state level.
> 
> information difficult, caching or not. Since doing the lookup 
> does not 
> require to actually place a 911 call, I can easily do 
> mappings from any 
> address I care to, at my leisure. I don't have to test all addresses, 
> just a few to get a very good idea whether, say, my local PSAP serves 
> the county or just one community.
> 

--snip--

The meaning of my above statement was that local PSAPs *could* hide behind a
state level infrastructure (a few have expressed a desire for this),
implying a possible double ecrit/routing mechanism.  First level would be
visible to the Internet and supply course-grain routing to a state level
B2BUA which would perform second level routing to the individual PSAP via a
'private' IP network.  In this case, it would be difficult to discover
individual PSAP jurisdictions.  Obviously, you can replace 'state' with any
other political level of choice.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Jul 2005 09:10:45 -0400

I tried to hint at that in other parts of the response, but multi-stage 
routing has indeed been my understanding. Just that my responses are 
already too long to begin with...

Maybe there's a requirement lurking here as well.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Jul 2005 13:34:43 -0400

> I suppose things like indexes and all those nice little data  management 
> bits come from free on the disks you buy?  I have a  SleepyCat database 
> of 4 million IPs sitting on my disk.  Using your  guidelines, the 
> database size should only be 20 meg ( (4 bytes for  IPv4 key + 1 byte of 
> value) * 4m ).  Yet, it appears to be 448 meg.
> 

I wasn't trying to design the database on the mailing list, as this will 
strongly depend on the particular implementation. I had deliberately 
used very large, round values to cover the variability in 
implementation. Are you disputing that even a national database, index 
and all, could easily fit on a modern disk costing ~$100?

Just for fun, I checked a large SQL database I run:

104,373,568 bytes data; 93,603,840 bytes index.

> This is the real problem.  How slowly?  How often is an emergency  call 
> made from every address, or even from most addresses?  If the  TTL is 
> set to 5 years, that means changes in the mapping must wait 5  years to 
> fully propagate.  If the TTL is 6 months, won't most entries  expire out 
> of the cache?

My caching model is different. If you can, you ask for the current 
information. If you can't (because you can't reach the server) you may 
use somewhat stale information since the alternative is no service at 
all and the likelihood of invalidation is low. The period of outages you 
need to "hide" with caching is probably measured in a few days (think 
flooding and hurricanes that interrupt wide-area access), not months.

As I said before, there is no need to have emergency calls be made from 
each address for this to work. Address verification and testing, things 
we agreed on as being valuable, will fill the cache. (Just because 
somebody won't *require* address verification to use the service, it is 
still prudent to make sure that the location information you have can be 
resolved to an emergency-answering URL before an actual emergency call.)

> game could be quite lengthy.

I'm not sure I understand. Most PSAP service boundaries follow state, 
county or city boundaries. Such boundaries are publicly documented and 
available for free from various electronic and paper sources. Why would 
this be harder for geo coordinates?

> 
> But you've assumed a system where the client runs the actual  geographic 
> mapping algorithm and not the server.

Not really. I'm assuming that the "local" mapping server contacted by 
the client (end system or outbound proxy, say) maintains a set of 
boundary polygons that are of local interest. To make this concrete: 
Assume that Verizon in NJ offers Internet services and also offers ECRIT 
mapping services to its subscribers; the ECRIT server would be located 
in the same POP they house their DNS and DHCP servers. That server would 
cache a few hundred polygons for the service areas of NJ PSAPs.

If Vonage, say, were to offer such an ECRIT mapping service, they may 
need to cache 6000 polygons, since their service footprint is national 
rather than regional.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Jul 2005 14:14:36 -0400

On Jul 1, 2005, at 1:34 PM, Henning Schulzrinne wrote:

> information. If you can't (because you can't reach the server) you  
> may use somewhat stale information since the alternative is no  
> service at all and the likelihood of invalidation is low.

So for the normal use case, you have added latency and inserted a  
single point of failure.

Seeing that there are many different caching methods, database  
replication methods, and fault-tolerant architectures that could  
address this problem, I think this is out of scope for defining the  
query interface that a client is to use as any number of these things  
could be used.  This does seem like a deployment consideration, but  
not a protocol requirement.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Jul 2005 15:30:38 -0400

> So for the normal use case, you have added latency and inserted a  

We're obviously not communicating. For the "normal" case, you can either 
rely on locally cached data (if available and fresh) or go ask the 
authoritative source. There's a trade-off you can't avoid: asking on 
demand takes time, but you can change the data on a minute-by-minute 
basis. The protocol needs to allow operators to tune the fresh vs. fast 
button.

This has nothing to do with single points of failure.

> could be used.  This does seem like a deployment consideration, but  not 
> a protocol requirement.

Without caching and synchronization support in the protocol, you'll have 
the problems we discussed earlier, so this is more than a deployment 
issue. As a slightly related example: DNS specifies zone transfer and 
caching, but there are obviously many different deployment architectures 
for DNS. Without the two functions, however, we would only be able to 
deploy closed DNS systems where the reliability is magic hidden behind 
some proprietary interface.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Jul 2005 16:52:08 -0400

> This has nothing to do with single points of failure.

The box you are insisting on putting between the client and the  
mapping service is a single point of failure.

> Without caching and synchronization support in the protocol, you'll  
> have the problems we discussed earlier, so this is more than a  
> deployment issue. As a slightly related example: DNS specifies zone  
> transfer and caching, but there are obviously many different  
> deployment architectures for DNS. Without the two functions,  
> however, we would only be able to deploy closed DNS systems where  
> the reliability is magic hidden behind some proprietary interface.

First, zone transfers in DNS are not related to answering normal DNS  
queries such as converting a domain name to an IP address.  In fact,  
most DNS administrators either turn it off or severely restrict to  
whom it will answer.  None of the name servers my company run get  
their data via zone transfer, yet we answer a lot of DNS queries  
every second.

Second, the caching you describe does not sound like DNS caching.   
DNS caches usually do not contain ALL the data from ALL the  
authoritative servers they talk to.  And they generally don't query  
the authoritative servers upon a cache hit just to see if the data  
has changed.

What you have been describing is not a cache like what we have with  
DNS.  You are describing some form of database replication.  How that  
database replication works does not need to be mixed in with the  
protocol used by the client to do a location-to-uri mapping query.   
Those are two different functions.

You stated earlier in this thread that "caching" is one of many ways  
to meet your suggested requirement.  If there are multiple ways, does  
the client query interface have to support them all?  I doubt it.

You can still do your database replication without putting that in  
the query interface.  That is why this is out of scope.

-andy

---

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

Andrew Newton wrote:
> The box you are insisting on putting between the client and the  mapping 
> service is a single point of failure.

I'm sorry, but I'm not sure which box you're talking about. If you mean 
the box run by the ISP or VSP, it clearly can't be a single box, just 
like no sane ISP will put a single local DNS server in its network. I 
would consider this pretty obvious, but maybe this isn't.

> most DNS administrators either turn it off or severely restrict to  whom 
> it will answer.  None of the name servers my company run get  their data 
> via zone transfer, yet we answer a lot of DNS queries  every second.

I think it would help the discussion if you didn't put words in my 
mouth. I never said that zone transfers are used to answer normal queries.

> 
> Second, the caching you describe does not sound like DNS caching.   DNS 
> caches usually do not contain ALL the data from ALL the  authoritative 
> servers they talk to.  And they generally don't query  the authoritative 
> servers upon a cache hit just to see if the data  has changed.

The detailed cache algorithm is a trade-off. The principle is the same.

It's an orthogonal issue as to whether they should query the 
authoritative server or not for each query; in DNS, the TTL allows you 
to set this and there seem to be quite a few that set that value close 
to zero (e.g., Akamai-style resolvers).

> Those are two different functions.

Zone transfer is a form of "database replication". Clearly, 
implementations can support a multitude of mechanisms, but having a 
standardized one has made DNS significantly more robust and allows 
mixed-software, loosely-coupled deployments (which is a good thing to 
avoid catastrophic failure). We (Columbia) can run a secondary at UMich, 
without worrying about whether UMich runs bind or some other DNS server.

> 
> You stated earlier in this thread that "caching" is one of many ways  to 
> meet your suggested requirement.  If there are multiple ways, does  the 
> client query interface have to support them all?  I doubt it.

I suppose it's incumbent upon those designing hypothetical protocols 
without such support to show that they can survive the same failure 
scenarios with equal probability, without relying on "and then there's 
magic".

> 
> You can still do your database replication without putting that in  the 
> query interface.  That is why this is out of scope.

I strongly disagree with that conclusion.