Summary: An Architecture for Content Routing Support in the Internet

The authors point out that the latency overhead incurred while trying to
locate the content using DNS can be high enough to offset any gain brought by
delivering the content from a nearby server. Instead, they propose that
searching for and retrieving content should be handled in a unified step in
order to keep the total number of RTTs down.

Rather than playing tricks with DNS, the authors advocate thinking of "the
content routing problem... as literally, a routing problem". They model the
system as a client at one end, and content at the other, with various
alternate paths to the content passing through routers and servers. Finding
the best path to a certain piece of content is therefore analogous to finding
the best path to a given host.

The authors adapted BGP to communicate content routing data between "content
routers". These routers take a DNS-like name for content, such as
bar.foo.com, and pass the request on to the next router in the hop that
minimizes some metric (ie. latency). Aggregation for content names with
common suffixes works much like IP address prefix matching.

Unlike ordinary BGP, it would appear that the approach described in this paper
uses symbolic names instead of addresses as the "lookup key". In other
words, clients don't need to do any sort of name resolution prior to
submitting their content retrieval request to their upstream content router.

Just as in ordinary routing protocols, the content routing system can
dynamically adjust path weights in response to outages or hotspots in the
network. Furthermore, all of this is transparent to the client, since it is
never setting up connections to particular hosts, only asking for content.
The content routers could even automatically retry queries if they end up
forwarding them to unresponsive routers/servers. The whole system should be
more scalable as well, since there is no centralized component (ie. an set of
authoritative DNS servers for a zone) to overload.

The system also ensures that the content and lookups traverse the same path at
the IP-layer. This way, content that can be resolved will should always be
retrievable. The system should never enter a state where the content
resolver locates the content, but the content delivery system can't actually
retrieve the material due to a link-outage, etc.

I thought this was a pretty neat idea. The motivation seemed very clear --
existing content delivery systems have to make some sort of performance vs.
reliability compromise given the fact that they rely on DNS. This system has
the potential to get the best of both worlds.
Received on Thu Nov 30 2006 - 02:49:30 EST