An Architecture for Content Routing Support in the Internet

From: shvet <shvetank_at_gmail.com>
Date: Mon, 4 Dec 2006 00:12:58 -0500

Motivation: The goal of content routing is to reduce the time needed to
access content. Using originating IP address of a DNS request can itself
lead to long latency. Hence, the content routing problem should be seen as
literally a routing problem in order to reduce latency.

Key Points:

1) Name based routing protocol provides a solution to replica location,
called *Content Routing*. A "content name" such as "cnn.com" is advertised
by each of the replica sites, so that the initial name lookup proceeds
directly to the closest replica. The content name maps to a list of replica
servers, rather than directly to an address

2) The list of replica servers may be ordered to reflect current preference
values and weights attached to servers.

3) Fate sharing - Content routing introduces fate sharing. Path to DNS
server may be broken or congested even though the path to content is fine.

4) Scalability is achieved by combining collections of name suffixes
into *routing
aggregates*.

The idea is interesting although the paper doesnt compare real scenario when
often the DNS entry has been cached at the local DNS server. The authors
also claim that it is more responsive to network conditions. The claim of
the authors in the opening section of most of the traffic being http traffic
and real audio streams is incorrect. With the surge of P2P traffic the
scenario has changed considerably as has been found and confirmed by various
measurement studies.
However, name based routing does hold promise as it can provide improved
fate-sharing between naming and packet delivery, improved lookup latency,
lower load upon root name servers, and a natural caching hierarchy.

I think the tussle here is more fundamental. Bringing together services like
lookup and routing does have advantages but it also compromises the
playground for tussle. I think flexibility is also needed so that things
evolve on independent vectors and collapsing services makes it problematic
for services to be flexible. However, such approaches should be researched
although we should be cautious in applying them.
Received on Mon Dec 04 2006 - 00:13:11 EST

This archive was generated by hypermail 2.2.0 : Mon Dec 04 2006 - 00:13:13 EST