Subject: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00

From: Andrew Newton <[email-masked]>
Date: Tue, 1 Nov 2005 11:57:59 -0500

Having read draft-schulzrinne-ecrit-mapping-arch-00, here are my  
comments:

1) Overall, this draft does a good job laying out a very specific  
mapping data distribution architecture.  I think it is worth noting  
this architecture as some may find it useful.  However, I can see how  
some people will view it as too many moving parts and may want  
something simpler.

2) I think the reference to DNS in the abstract should be stricken as  
the architecture described sounds like a lot more than DNS.

3) I really like the definition of "seeker".  So much so, that  
something similar ought to be added to the ECRIT requirements  
document.  It is basically a term that says, "there are multiple  
types of nodes that may initiate these queries, and we call all such  
nodes conducting this function a 'seeker'".

4) Section 3.1 says that LCMS services requires distributed  
services.  I disagree with that.  It could certainly be done in a  
centralized manner, and I suspect that some parts of the world will  
adopt a centralized system.

5) It is probably worth mentioning that the protocol between the  
seeker and the resolver may not be the same as the protocol between  
the forest guides and the other architecture elements, as it would  
make no sense to impose upon the seeker the mesh semantics.

6) There is no discussion about how geospatial coordinates are used  
in this hierarchical system, or rather how they are mapped into the  
system.

7) Section 8 seems to be on an entirely different subject.  Perhaps  
it should be broken out into its own draft.

-andy

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Nov 2005 16:45:23 -0500

Andrew Newton wrote:
> Having read draft-schulzrinne-ecrit-mapping-arch-00, here are my  comments:

Andrew,

thanks for taking the time to read the draft. Many of your points 
deserve a fuller response, but I wanted to get the discussion started.

> some people will view it as too many moving parts and may want  

I'm all for simplicity, but I believe we need to deal with the 
real-world issue that information about mappings is naturally 
distributed and owned by a variety of parties that don't necessarily 
know about or trust each other. In some circumstances, you can simplify 
the system by combining the roles of resolvers and forest guides, for 
example.

I'm certainly interested in simpler architectures, but I'm very wary of 
assuming, say, a single hierarchy or a single logical root. I'd rather 
deal with some technical complexity than inventing another ICANN or 
public ENUM.

I'm also hoping that the implementation complexity is modest. I think 
you essentially need two or three message types between the various 
components.

> the architecture described sounds like a lot more than DNS.

It's the closest analogy I could think of. No analogy is perfect, but 
there are clear similarities:

- hierarchical, with distributed ownership of data

- caching resolvers at the edge

- notions of forwarding queries

Besides the basic difference of not mapping name labels DNS-style, I 
think the major architectural difference is the absence of a small root. 
We don't have the technical limitations that force a small root server 
population (ignoring the current anycast approach).

But maybe you could explain the "a lot more" part so that I can better 
understand your point.

> document.  It is basically a term that says, "there are multiple  types 
> of nodes that may initiate these queries, and we call all such  nodes 
> conducting this function a 'seeker'".
> 
> 4) Section 3.1 says that LCMS services requires distributed  services.  
> I disagree with that.  It could certainly be done in a  centralized 
> manner, and I suspect that some parts of the world will  adopt a 
> centralized system.

Maybe we have a very different picture of how this would work, but 
unless we have a single centralized system for the whole world, you'd 
still have to find the various "centralized" systems for each country, 
depending on where you are.

Cast in the terminology of my draft, this would mean that each country 
would have a tree consisting of one tree node, so this is just a special 
case. You'd then need a way to find these (short) trees. In other 
contexts, DNS has been suggested for that. But then you have to know 
which country you are in based on your GPS coordinates, and you then 
essentially get to run Brian's DNS system as well as the some other 
system, increasing the overall complexity (and still having to deal with 
the global root issue).

Maybe you can suggest a way to automatically, without manual 
configuration, bootstrap a centralized system, as I'm probably just not 
seeing the simple solution you have in mind.

> 
> 5) It is probably worth mentioning that the protocol between the  seeker 
> and the resolver may not be the same as the protocol between  the forest 
> guides and the other architecture elements, as it would  make no sense 
> to impose upon the seeker the mesh semantics.

I think I mention protocol diversity somewhere, but I'll check. My 
general perception is that since this is an international system, 
keeping the number of diverse protocols small is beneficial for 
simplicity and interoperability. I suspect that, in practice, we'll see 
implementations that can fulfill multiple roles (such as resolver, 
authoritative server and forest guide), just like we have generic DNS 
servers (e.g., BIND or for LDAP) today, as well as more specialized ones.

> 
> 6) There is no discussion about how geospatial coordinates are used  in 
> this hierarchical system, or rather how they are mapped into the  system.

This probably needs clarification, but the intent was that there is no 
special mechanism. Regions can be polygons or civic regions. A query for 
a point in geospatial coordinates is handed to a server, which finds the 
appropriate region and sends the query down that tree branch.

If you find a particular place where the discussion only applies to 
civic coordinates and needs special treatment for geo, please let me know.

No, I'm not trying to start another civic-vs.-geo discussion with this 
draft, although we're well overdue for an encore performance...

> 
> 7) Section 8 seems to be on an entirely different subject.  Perhaps  it 
> should be broken out into its own draft.

While this appears separate, I actually believe that it is essentially 
the same problem: map location to a (set of) URLs. Thus, I think the 
overall system complexity can be greatly reduced by integrating this 
information. That way, end systems make one query and get back both 
their local emergency numbers and their emergency contact, with the 
minimal complexity of one additional XML element in the response. I 
would hate to have to build a whole new architecture just for this one 
piece of relatively trivial location-dependent configuration information.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 4 Nov 2005 13:15:13 -0500

On Nov 3, 2005, at 4:45 PM, Henning Schulzrinne wrote:
> I'm certainly interested in simpler architectures, but I'm very  
> wary of assuming, say, a single hierarchy or a single logical root.  
> I'd rather deal with some technical complexity than inventing  
> another ICANN or public ENUM.

I agree completely with this.  So I suspect that you and I are  
miscommunicating.

>> 2) I think the reference to DNS in the abstract should be stricken  
>> as  the architecture described sounds like a lot more than DNS.
>>
>
> It's the closest analogy I could think of. No analogy is perfect,  
> but there are clear similarities:

I think LDAP is a better analogy.

> Besides the basic difference of not mapping name labels DNS-style,  
> I think the major architectural difference is the absence of a  
> small root. We don't have the technical limitations that force a  
> small root server population (ignoring the current anycast approach).

That, and the forest guides.

>> centralized manner, and I suspect that some parts of the world  
>> will  adopt a centralized system.
>>
>
> unless we have a single centralized system for the whole world,  
> you'd still have to find the various "centralized" systems for each  
> country, depending on where you are.

Not for the whole world, but I can certainly imagine smaller  
countries adopting for a nationwide centralized system.  The whole  
notion of a highly decentralized system is only really relevant to  
the US.

> Cast in the terminology of my draft, this would mean that each  
> country would have a tree consisting of one tree node, so this is  
> just a special case. You'd then need a way to find these (short)  
> trees. In other contexts, DNS has been suggested for that. But then  
> you have to know which country you are in based on your GPS  
> coordinates, and you then essentially get to run Brian's DNS system  
> as well as the some other system, increasing the overall complexity  
> (and still having to deal with the global root issue).
>
> configuration, bootstrap a centralized system, as I'm probably just  
> not seeing the simple solution you have in mind.

Then I do not understand what you are proposing with this  
architecture.  How are you bootstrapping the knowledge of the  
resolvers and the forest guides?

>> 6) There is no discussion about how geospatial coordinates are  
>> used  in this hierarchical system, or rather how they are mapped  
>> into the  system.
>>
>
> This probably needs clarification, but the intent was that there is  
> no special mechanism. Regions can be polygons or civic regions. A  
> query for a point in geospatial coordinates is handed to a server,  
> which finds the appropriate region and sends the query down that  
> tree branch.
>

I guess this goes to my question above.  In the system you are  
proposing, how do I know which resolver or forest guide to  send a  
query to when all I have is geo coordinates?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Nov 2005 19:02:39 -0500

> I think LDAP is a better analogy.

I agree that this is close, but my impression was that LDAP was rarely 
used in a hierarchical way, with referrals and redirections (or other 
intermediaries). I only see the traditional corporate address book 
server, i.e., a single server hosting the whole database. But that may 
not be the whole picture.

> That, and the forest guides.

They are essentially a distributed root, but I agree that this is the 
major big-picture difference. Maybe the lesson here is to avoid a simple 
analogy and highlight some similarities and differences.

> 
> Not for the whole world, but I can certainly imagine smaller  countries 
> adopting for a nationwide centralized system.  The whole  notion of a 
> highly decentralized system is only really relevant to  the US.

Let me be more precise: If the lookup is being performed by your VSP, 
e.g., in its outbound proxy, the VSP may be located in a completely 
different country than the caller. (My current VSP-of-choice happens to 
be located in Germany.) In that model, each VSP would have to keep track 
of every directory/tree in the world. I don't think that's a desirable 
model, as it implies too much manual configuration.

Maybe this is a requirement discussion; I thought we had general 
agreement that the lookup function can be performed either by the end 
system or by an outbound proxy used by the caller, presumably operated 
by the VSP.

> architecture.  How are you bootstrapping the knowledge of the  resolvers 
> and the forest guides?

I'm picturing using the standard ISP or VSP configuration mechanism. The 
VSP configuration (e.g., SIP config) or ISP configuration (e.g., DHCP) 
would point to a resolver. Since every resolver has access to the forest 
guides, it doesn't much matter if the seeker picks the ISP or the VSP 
resolver, except maybe in terms of network proximity. The resolver 
operator just has to find one suitable forest guide, just like they 
configure NTP servers, for example.

> query to when all I have is geo coordinates?

The forest guides have a collection of polygons ("regions"), one for 
each tree. Thus, they know how to find the right tree(s). The resolver 
is pre-configured by the ISP or VSP with one or more forest guides. If 
we take the one-tree-per-country model, there'd be about 200 of those 
maps, which seems pretty manageable, particularly given that these don't 
tend to change on a day-by-day basis.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Fri, 4 Nov 2005 19:30:41 -0500

On Nov 4, 2005, at 7:02 PM, Henning Schulzrinne wrote:
> I agree that this is close, but my impression was that LDAP was  
> rarely used in a hierarchical way, with referrals and redirections  
> (or other intermediaries). I only see the traditional corporate  
> address book server, i.e., a single server hosting the whole  
> database. But that may not be the whole picture.

LDAP is hierarchical in its model.  Its basic data structure is a  
tree.  As for the corporate address book, it is possible to setup a  
separate branch for each department. I suspect that in corporations  
that allow multiple LDAP branches, they may also allow multiple DNS  
tertiary delegations.  If you through in the concept of LDAP  
centroids, well it looks much more like what you are proposing.

> I'm picturing using the standard ISP or VSP configuration  
> mechanism. The VSP configuration (e.g., SIP config) or ISP  
> configuration (e.g., DHCP) would point to a resolver. Since every  
> resolver has access to the forest guides, it doesn't much matter if  
> the seeker picks the ISP or the VSP resolver, except maybe in terms  
> of network proximity. The resolver operator just has to find one  
> suitable forest guide, just like they configure NTP servers, for  
> example.

While using the VSPs knowledge of the world is good fallback, the  
most desirable configuration is the ISPs.  That way, the resolvers/ 
forest guides do not have to have a global view of where everything  
is.  They just need to know about their area of the planet.

>> proposing, how do I know which resolver or forest guide to  send  
>> a  query to when all I have is geo coordinates?
>
> The forest guides have a collection of polygons ("regions"), one  
> for each tree. Thus, they know how to find the right tree(s). The  
> resolver is pre-configured by the ISP or VSP with one or more  
> forest guides. If we take the one-tree-per-country model, there'd  
> be about 200 of those maps, which seems pretty manageable,  
> particularly given that these don't tend to change on a day-by-day  
> basis.

Ok.  So you are saying that there are one or more forest guides per  
country (load balanced via whatever mechanism, anycast, SRV,  
whatever).  The operation of the forest guides is a governmental  
issue, and the configuration of which country cares about which other  
countries information is up to that operation (i.e. if the US doesn't  
want to interact with Iran's servers, oh well).  Do I have this right?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Nov 2005 19:53:33 -0500

> tertiary delegations.  If you through in the concept of LDAP  centroids, 
> well it looks much more like what you are proposing.

I'll mention this is my comparison.

> While using the VSPs knowledge of the world is good fallback, the  most 
> desirable configuration is the ISPs.  That way, the resolvers/ forest 
> guides do not have to have a global view of where everything  is.  They 
> just need to know about their area of the planet.

But that requires that every ISP has this information, even if they know 
nothing about VoIP services. This doesn't seem very likely. There's also 
the practical problem that I might get my DHCP information from a 
Linksys box, which doesn't know anything about this. Thus, while I agree 
that ISPs are a good source of this information, I don't think we can 
design a system that *requires* that all of them provide this information.

> whatever).  The operation of the forest guides is a governmental  issue, 
> and the configuration of which country cares about which other  

The forest guides don't have to be operated by a government. Imagine a 
company called OldMoon that wants to play in this space. It would work 
with national or regional trees to get their coverage regions and would 
interconnect with other providers that also have some of this knowledge, 
spreading it among the forest guides. The geographic location of this 
company wouldn't really matter much, just that trees were willing to 
connect to them and send them (very infrequent) region updates.

Each tree could feed its region information to any (reasonable) number 
of forest guides. This might include not-for-profit organizations (say, 
NENA), commercial data brokers or maybe even large carriers (VSP or 
ISP). They just have to be willing to spread data.

With the danger of introducing dubious analogies, think of Usenet, 
except that the data volume is orders of magnitude *less*.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Sat, 5 Nov 2005 11:13:22 -0500

On Nov 4, 2005, at 7:53 PM, Henning Schulzrinne wrote:
> But that requires that every ISP has this information, even if they  
> know nothing about VoIP services.

Well, we certainly do have a conundrum here.  Because much of the  
ECRIT system relies on the ISPs having location information and  
operating location delivery protocols.  Beyond VoIP, I doubt there  
are many solid reasons for them to do so.

Still, I agree that VSPs are important when ISPs can't do what we need.

> The forest guides don't have to be operated by a government.  
> Imagine a company called OldMoon that wants to play in this space.  
> It would work with national or regional trees to get their coverage  
> regions and would interconnect with other providers that also have  
> some of this knowledge, spreading it among the forest guides. The  
> geographic location of this company wouldn't really matter much,  
> just that trees were willing to connect to them and send them (very  
> infrequent) region updates.
>
> Each tree could feed its region information to any (reasonable)  
> number of forest guides. This might include not-for-profit  
> organizations (say, NENA), commercial data brokers or maybe even  
> large carriers (VSP or ISP). They just have to be willing to spread  
> data.

I didn't necessarily mean a government agency directly running it.   
But I get your point.
Thanks.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Nov 2005 11:27:21 -0500

Andrew Newton wrote:
> Well, we certainly do have a conundrum here.  Because much of the  ECRIT 
> system relies on the ISPs having location information and  operating 
> location delivery protocols.  Beyond VoIP, I doubt there  are many solid 
> reasons for them to do so.

Clearly, things work much better if the ISP plays along. I just don't 
think we can design a system that *requires* that it does so. As you 
know, the current I2 system relies on user-entered location information 
for residential users, for example, not requiring any ISP involvement. 
This is far from ideal, but seems likely to be with us for quite a while.

This is a separate discussion, but I'm starting to believe that we need 
to think beyond the traditional top-down approach of location 
determination. There is evidence that cooperative location 
determination, such as beta.plazes.com or PlaceLab 
(http://www.placelab.org/) might be able to provide first-order 
approximations in cases where nothing better is available.

Henning