I Told Him We Already Got One!

Reading about one of the many proposals for a brand new Internet recently reminded me of the famous Monty Python Scene where King Arthur offers to allow the Master of the French Guards to join him in his quest for the holy grail, and the guards respond by saying they've already got one. It felt to me like those proposing a new Internet architecture were doing much the same by inviting others to join them in a quest for a holy grail, except that the invitees really do already have a grail that works nicely. This issue is not common to the Internet. Those on the fringes of programming language research, for example, have claimed that the current crop of programming languages is insufficient for the parallel programming needs of the future, and yet the industry still churns out code well enough using existing tools. And, of course, one need not look long beyond the field of computing to see scenarios where change is resisted because the status quo is good enough.

In the paper I read, "A Data-Oriented (and Beyond) Network Architecture", the author proposes layering a name-based anycast protcol atop IP in order to more properly fulfill three current primary needs that the original Internet did not foresee: persistence, availability, and authenticity. It is interesting to learn how the architecture proposed in this paper meets these needs relative to how the current Internet handles them.

First is name-based persistence. The authors believe that as long as the data or service underlying a particular name is available, a user should be able to access it using that name. Currently, this is handled through the DNS system. If the resource underlying a URL moves, the distributed DNS system must be updated as to its new location. Intermediate measures like redirects are needed until all DNS caches have been updated. In contrast, using the anycast protocol described in the paper, a moved resource will most likely still remain in the same AS in which it originated, and since routing at the naming level occurs between AS's, no updating of the route handlers will need to occur most of the time. However, updates will still need to occur if inter-AS movement occurs, and the authors also appear to ignore the issues of reliability and failover, which suggests that a new TCP-like service would need to be built on the named routing layer to maintain functionality similar to the existing Internet.

Secondly, the proposed named routing system encourages the replication of data to multiple nodes for both high availability and low latency access. The routing system is designed to handle the ambiguity of multiple locations for a named piece of data by allowing route handlers to choose the current "best" route to the named entity. Currently, the Internet provides this type of service through the use of content distribution networks like Akamai. From my limited understanding on the matter, the routing layer already allows for multiple locations for a single IP address, enabling these systems to route a client to the nearest copy of data made available by the CDN instead of the location of the original data or service. While I have been told that routing table sizes are growing at an alarming rate, I do not know at what point this issue will have a visible impact on the level of service provided by the current Internet infrastructure.

Lastly, the named routing system integrates an authentication scheme into the system through the use of asymmetric encryption keys, allowing anyone to verify that the server of a service or piece of data is authorized to serve that content. This same feature is currently provided through the use of SSL certificates verified by a third party VeriSign. Since I am not an expert in security, I do not know the difficulty in performing authentication attacks against the current system relative to performing the same attacks on the system proposed in the paper, but the proposed system is likely inherently more secure and easier to implement than the system the current Internet uses.

Again, the new Internet system described in the paper was conceived to more correctly handle needs that the current Internet is meeting but for which it was never designed to handle. At what point will existing solutions be sufficiently worse than such a system that upgrading begins to be seen as cost-effective? For now, the Internet, decades old as it is, already seems to handle all of these needs effectively enough.