Subject: [RRG] thoughts on the design space 4: encapsulate vs. translate

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Jul 2008 15:23:58 +0300

My other conclusions relate to the choice between encapsulation and 
translation.

First, I think we need to consider this choice in the context of the 
entire functionality, including interworking with the legacy Internet. I 
like the proxy encapsulator (PTR) design, and would far prefer that to 
translation. However, as discussed before its unclear if this is 
deployable due to incentive issues. For the moment, that leaves 
translation as the deployable interworking scheme.

I do not care much whether the upgraded-to-upgrade traffic uses 
encapsulation or translation. That's a detail in many ways.

So for the moment this leaves me with the following "best" design:

1. Employ something like NERD for the mapping table, no caching
2. Identifier spaces are allocated per organization, PI style, and we do 
not attempt to solve the host identifier-locator split
3. Translate or encapsulate when talking from an upgraded network to 
another upgraded network
4. Translate when talking to a legacy network

While this is "best" solution in my today's opinion, the big question in 
my mind is whether it is good enough, and what the drawbacks are. I 
understand that Christian has been making some progress in eliminating 
some NAT effects from translation design when using IPv6. However, how 
significant are the remaining ones? I share the concerns with Brian. 
Also, the entire system has a number of other implications, such as 
effects to referrals, and increased complexity.

Jari

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jul 2008 22:36:42 -0700

> 2. Identifier spaces are allocated per organization, PI style, and  
> we do not attempt to solve the host identifier-locator split

Jari, can I ask you one question. Does your host have every DNS name  
in the Internet cached (or should I not use the evil word "cache" but  
"stored" instead)? Why not? If you did, you wouldn't get delays  
connecting to your favorite web sites. Do you think it's practical?  
And if so, why hasn't it been deployed in our DNS implementations?

Dino

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 25 Jul 2008 21:02:02 +0200

Jari,
> 1. Employ something like NERD for the mapping table, no caching

By doing this, you assume that the only benefits of a mapping system is 
to reduce the number of prefixes carried on core routers. In this case, 
a static mapping system could be acceptable, but a mapping system can 
offer many more benefits than simply improving the scalability of the 
core routers. A dynamic mapping systems can allow sites to do much more, 
see :

http://inl.info.ucl.ac.be/publications/evaluating-benefits-locatoridentifier

> 2. Identifier spaces are allocated per organization, PI style, 

I agree, this is key for the scalability of the mapping system. A single 
mapping reply should provide mapping information for a (preferably 
large) set of identifiers

> and we do 

I think that in some environments locators would be attached only to 
routers while in other environments locators would be attached to (at 
least some) hosts. The architecture should support this, at least in the 
long term.

Olivier
-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: "William Herrin" <[email-masked]>
Date: Fri, 25 Jul 2008 17:23:04 -0400

On Fri, Jul 25, 2008 at 1:36 AM, Dino Farinacci <[email-masked]> wrote:
> Jari, can I ask you one question. Does your host have every DNS name in the
> Internet cached (or should I not use the evil word "cache" but "stored"
> instead)? Why not? If you did, you wouldn't get delays connecting to your
> favorite web sites. Do you think it's practical? And if so, why hasn't it
> been deployed in our DNS implementations?

It *was* deployed and called "hosts.txt".  See RFC 1034 Section 2.1.

s/host name/identifier/g
s/address/locator/g

Regards,
Bill

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Jul 2008 14:27:50 -0700

> It *was* deployed and called "hosts.txt".  See RFC 1034 Section 2.1.

Right and look at the value of the RFC number.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Fri, 25 Jul 2008 14:38:25 -0700

|Right and look at the value of the RFC number.

If your implication is that low RFC numbers are bad, then please see RFC
791.  ;-)

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Jul 2008 16:09:50 -0700

> If your implication is that low RFC numbers are bad, then please see  

My implication was that that was a long time ago and the number of  
hosts have grown maybe 4 orders of magnitude, and I am conservative  
with my exponent.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Fri, 25 Jul 2008 16:31:16 -0700

|My implication was that that was a long time ago and the number of  
|hosts have grown maybe 4 orders of magnitude, and I am conservative  
|with my exponent.

Fair.  I think it's also fair to assert that the number of identifiers that
we need to support is linear with the number of hosts (and thus hostnames)
that we need to support.

Further, we can assert that DNS supports mappings of this scale and does so
in a caching fashion.  However, DNS is NOT invoked for anonymous
transactions and if it was, it would not scale appropriately.  Imagine
Google doing a reverse DNS lookup on every packet it receives, for example.

Do folks agree?

Tony

---

From: "William Herrin" <[email-masked]>
Date: Sat, 26 Jul 2008 00:08:40 -0400

> Google doing a reverse DNS lookup on every packet it receives, for example.

Tony,

That's not an equivalent comparison for two reasons:

1. You don't do a lookup for every packet; you do a lookup for the
first packet in a time-bounded series. That's true for both the
query-cache map proposals and the DNS. Doing a lookup for every packet
would be asinine.

2. Reverse-DNS lookups are often -much- less efficient that forward
lookups. Hierarchy servers for forward lookups are typically held
together with glue to in-scope servers, so they go fast. Reverse
lookups are held together with servers from the forward hierarchies,
so for each level you descend in the reverse hierarchy you have to go
do a full traversal in the forward hierarchy to find the server
address. That's an operations deficiency rather than a protocol
deficiency. The reverse hierarchy could have been built with glue, but
no one perceived a need.

Despite that, you make a fair point.

The counterargument is this: for virtually every packet google
receives, the origin has already performed a DNS lookup in order to
get that far. If the first-packet time is already slowed to DNS-time,
what's the harm in a second lookup? Especially when the alternative is
hosts.txt.

There are counterexamples to that but they tend to cluster in three areas:

1. Local administrative access by IP address. That's out of scope
here: the map-encap protocol is used on non-local situations.

2. Protocols like bit torrent where the remote IP address has been
discovered through some other kind of lookup protocol. A mild lag in
bit torrent's initial connect to a new peer makes no difference to
anyone.

3. Worms hunting for machines to infect. No only don't we care if
these are delayed, we'd prefer that they be delayed. Forever if
possible. ;)

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Fri, 25 Jul 2008 22:52:41 -0700

Hi Bill,

|> Fair.  I think it's also fair to assert that the number of 
|identifiers that
|> we need to support is linear with the number of hosts (and 
|thus hostnames)
|> that we need to support.
|>
|> Further, we can assert that DNS supports mappings of this 
|scale and does so
|> in a caching fashion.  However, DNS is NOT invoked for anonymous
|> transactions and if it was, it would not scale 
|appropriately.  Imagine
|> Google doing a reverse DNS lookup on every packet it 
|receives, for example.
|
|That's not an equivalent comparison for two reasons:
|
|1. You don't do a lookup for every packet; you do a lookup for the
|first packet in a time-bounded series. That's true for both the
|query-cache map proposals and the DNS.

True, I should have said for each connection...

|Doing a lookup for every packet would be asinine.

But that's no reason to be rude about it.

|2. Reverse-DNS lookups are often -much- less efficient that forward
|lookups. Hierarchy servers for forward lookups are typically held
|together with glue to in-scope servers, so they go fast. Reverse
|lookups are held together with servers from the forward hierarchies,
|so for each level you descend in the reverse hierarchy you have to go
|do a full traversal in the forward hierarchy to find the server
|address. That's an operations deficiency rather than a protocol
|deficiency. The reverse hierarchy could have been built with glue, but
|no one perceived a need.

Good point.

|Despite that, you make a fair point.
|
|The counterargument is this: for virtually every packet google
|receives, the origin has already performed a DNS lookup in order to
|get that far. If the first-packet time is already slowed to DNS-time,
|what's the harm in a second lookup? Especially when the alternative is
|hosts.txt.

The issue, IMHO, isn't the delay, it's the scalability, especially in front
of hot spots like Google.  In these cases, it would make sense to have a
hybrid mapping, where we can install full mappings at hot spots.  

Note that it's not exactly analogous, as hosts.txt (at least on some systems
;-) needed a manual update.  This would be more equivalent to a mapping
crawler, so that the cost would really be in the state being held.

But, we again digress into mechanism.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Jul 2008 22:04:18 -0700

> Google doing a reverse DNS lookup on every packet it receives, for  

I believe a site will have less Map-Requests sent by the ITRs then DNS  
queries by all hosts at the site. The granularity of site reduces the  
number of requests and are reused by all other hosts that come later.

Dino

---

From: "William Herrin" <[email-masked]>
Date: Sat, 26 Jul 2008 09:28:29 -0400

> True, I should have said for each connection...

Hi Tony,

It isn't even per connection. It's per time-bounded series which is
likely to include many connections as necessary to complete a "visit"
by the person at the origin. A web server doesn't have a big cache of
recently-looked-up addresses. A hypothetical ITR does.

At least one map-encap approach take this a step further: a supply of
bare, non-multihomed and highly-aggregated network addresses remains
available on the Internet. In theory at least, applications and
servers requiring brief, anonymous connections can make use of this
supply, relying on map-encap only for the direction that must remain
stable over time.

> But that's no reason to be rude about it.

Apologies. Was not intended that way.

> hybrid mapping, where we can install full mappings at hot spots.

If we use DNS for our example assume that nearly all packet flows have
performed a DNS lookup at the client side in order to find the server
then  we're talking about tripling the load on the DNS system. Find me
a DNS op who doesn't believe the DNS system can readily expand to
serve triple the load.

On the flip side, the first connection is held open longer than normal
while the ITRs complete lookups. This has an impact on the web and
other servers. However, such connections are in the syn/synack stage.
So, the problem fits neatly into the generic syn-flood DOS attack
problem which is already solved.

Regards,
Bill

---

From: Jari Arkko <[email-masked]>
Date: Sat, 26 Jul 2008 16:57:41 +0100

Olivier,

> By doing this, you assume that the only benefits of a mapping system 
> is to reduce the number of prefixes carried on core routers. In this 
> case, a static mapping system could be acceptable, but a mapping 
> system can offer many more benefits than simply improving the 
> scalability of the core routers. A dynamic mapping systems can allow 
> sites to do much more, see :
>

I agree that we want more than merely the reduction of the # of 
prefixes. However, the question is what parts of that "more" rest on the 
mapping system and what is in the responsibility of the two networks 
talking to each other in an end to end fashion.

I a sense, I feel that we are talking about what information should be 
cached. What I was saying above was about the ID->LOC mapping table. I 
agree that a network A and network B need more information than this in 
order to do, for instance, failover and traffic engineering.

But does that information have to be in the mapping system? It is 
something that the two ends can also establish by themselves. In the 
process of discovering this information they may some cached state. For 
instance, one of the two edge routers is actually down.

This will also have similar effects as full-blown caching of all mapping 
information. You might lose a packet if one of the chosen edge router 
was down. You might have delay if you sent the packet to a non-preferred 
router. We need to find out if the effects of this type of caching are 
harmful, too. But I would expect the effects to be much less significant 
than in wholesale caching. (But if the effects turn out to be harmful, 
then we face a difficult problem of creating a large distributed 
database that also needs to change at a fast pace.)

>> and we do not attempt to solve the host identifier-locator split
>
> least some) hosts. The architecture should support this, at least in 
> the long term.
I'm not sure I understand what you are saying above. Can you elaborate 
this a bit?

Jari

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 28 Jul 2008 15:51:42 +0200

>
> I believe a site will have less Map-Requests sent by the ITRs then  
> DNS queries by all hosts at the site. The granularity of site  
> reduces the number of requests and are reused by all other hosts  
> that come later.
>
We proved this statement in:

http://inl.info.ucl.ac.be/publications/cost-caching-locatorid-mappings

Luigi

> Dino

Luigi Iannone

[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 31 Jul 2008 15:57:47 +0100

> If your implication is that low RFC numbers are bad, then please see  

The one you should really avoid is RFC 894: low number, published on  
April first, and breaks the relevant IEEE standard to boot...