Review - An Architecture for Content Routing Support in the Internet

Review of An Architecture for Content Routing Support in the Internet
by Ivan Hernández

The paper proposes a new type of routing Content Routing (CR) that
will reduce the time needed to access content. Currently, Content
Delivery Networks use specialized DNS to redirect a user to a nearby
content server to get the desired content; the problem with this
current solution is that to get the ip mapping of the desired domain
name, via DNS, the round-trips have "long" latency and the TTL of the
DNS records have small values, which requires the client to do
frequent "long" latency DNS requests.

The paper gives examples of things that can go wrong with the current
DNS-based solution to Content Delivery Networks. I found the proposed
solution is interesting. Nevertheless, I think that there are a couple
of issues. First, According to the paper, clients initiate a content
request by contacting a content router, just as they would contact a
preconfigured DNS server. So instead of getting the mapping from a DNS
server, the author put "DNS-servers" on the routers, these routers
does not have the ip-mapping, but the next-hop is chosen based on the
information associated with the known routes, in this way the router
forward the request to the best content server. Nevertheless there is
no clear explanation on how an organization is going to deploy all its
ip+domain name mappings. Second, which is the metric to decide which
next-hop is the best? The authors suggest that the Name-Based Routing
Protocol (NBRP) perform routing by name with a structure similar to
BGP, but it is not clear which will be the used metric. They suggest
what a routing advertisement "may" include, but it is not
defined. Next, when an INRP request reaches the content router
adjacent to the "best" content server, that router sends back a
response message containing the address of the preferred server; this
response is sent back along the same path of content
routers. Nevertheless, the authors does not explain how a router
knows, that it is "next" to the best content server. In addition, the
paper's aggregation solution "works" but is not clear that it can be
implemented efficiently given the length variability in the domain
names to aggregate. It will not be as efficient as the aggregation
mechanism used with 32 bit addresses used in IP. Furthermore, the
aggregation in IP assumes that all the addresses are contiguous, in
the solution presented in the paper the authors "patch" the
redirection solution by changing the name of the resource to look,
e.g., if gritter.stanford.edu is located in Berkeley, the name look up
returns a redirection to guest32.berkeley.edu.

Finally, the evaluation shows a mean improvement of 62ms, this is a
one-time improvement (just the first time that we get the domain-name
to ip mapping), the rest of the time is used to download the content
which is in the order of seconds for HTML pages and of minutes if the
content is audio or video; thus I think that the 62ms are negligible!
The question is, is it worthy to tho all infrastructure changes that
the authors propose, to gain on average just 62ms?
Received on Thu Nov 30 2006 - 09:55:58 EST