Caching in
Last week I attended the GENI workshop at UC Davis. GENI is an ambitious project to build a testbed for next generation network technologies such as new router algorithms.
One reason I am interested is that the GENI testbed would provide an environment that could allow meaningful experiments into security usability. Putting a user in a lab for an hour or so is a great way of working out if they are likely to buy a product or install it correctly. Lab experiments are a lousy way of predicting how a user might react to an unexpected attack in six months time when their own money is at stake.
As with most such projects, the objectives are considerably more ambitious than the funds on offer. This leads me to suggest a way to simplify the project: drop the plans to investigate new routing algorithms.
There are two reasons why routing is not an interesting or important field of study for publicly funded research. The first is that makers of routing hardware are already keenly interested in the problem, the second is that nobody is going to be interested in deploying a radical new routing scheme requiring a completely new suite of systems when Moore's law continues to deliver a 100% increase in gates every 18 months.
But the bigest reason to be suspicious of researching new routing techniques is that we already know an efficiency improvement that is orders of magnitude greater than anything a change to the core router transport makes possible, the problem is that we don't yet know how to deploy it.
As you probably guessed from the title, that efficiency improvement is edge caching. The best way to improve the efficiency of a network is not to send the data at all, or to send it only once. More on that in part II
