Four Myths about GENI

Download Report

Transcript Four Myths about GENI

Four myths about GENI
(and one recommendation)
Constantine Dovrolis
[email protected]
College of Computing
Georgia Tech
The summary of my position

The main motivations behind GENI and FIND are
questionable





Myth-1: The “lack of adoption” argument
Myth-2: “An experimental facility such as GENI will lead to better
networking research (or higher deploy-ability)”
Myth-3: “The Internet architecture is ossified”
Myth-4: “Clean-slate architectural research will lead to a better
future Internet than the evolution of the current architecture”
A recommendation to NSF and the research community:



Do not put all your eggs in one basket
Embrace and support evolutionary Internet research
Provide experimental facilities that evolutionary research
desperately needs
Myth-1: If the real-world does not adopt our
architectures/protocols, then something is wrong with
the real-world..

Or is it that something is wrong with our architectures and
protocols?



GENI proponents say that the real-world (mostly ISPs and router
vendors) does not have the incentive to deploy innovations at the
network layer
In reality though, ISPs never stopped deploying new
protocols/technologies when they actually need them


What happened to IPv6, IntServ, IP Multicast, and so many other
architectural proposals?
Think of MPLS, BGP route reflectors, traffic
classifiers/differentiators at forwarding plane, NIDS, etc
The real-world adopts “evolutionary mutations” that address a real
need and provide an advantage/gain to the deployer

Think in biological terms: mutations, natural selection, survival of
the fittest
Myth-2: Prototype implementations and testbed
experiments will lead to increased deploy-ability

Most previously proposed “failed architectures” were actually
implemented and run on various testbeds




The main issue with any testbed/experimental facility is that it
does not carry real user traffic


Real users will not use a buggy/experimental network
Plus, a testbed cannot capture the complex economic/incentive
issues that were the key factor behind the failure of many
previous architectures


Remember MBone? 6-Bone? RSVP+IntServ implementations?
Testbeds and prototypes do not prove “deployability”
All recent congestion control proposals (e.g., XCP) have been
implemented and run on testbeds
Routing research without considering policies and incentives?
On the other hand, the real-world has repeatedly deployed new
protocols/technologies that lacked testbed experiments, but
that evolved while running in production networks

Think of the long TCP evolutionary path
Myth-3: The Internet architecture is ossified



What can we learn from biology and complex systems?
 In any complex system, the core components (evolutionary
kernels) need to be conserved, so that complexity and
diversity can emerge at the periphery of the system
 Think of Doyle’s bow-tie architecture, or the TCP/IP waist
of the protocol hourglass
The network layer represents an evolutionary kernel. It
needs to be conserved (few and minor changes) so that
innovation and diversification can continue at the
transport/application layers and at the physical/link layers
 My (serious) prediction: The Internet of 2020 will be running
a backwards-compatible, evolved version of IPv4
The research community needs to understand the
“conservation of evolutionary kernels” principle, and focus its
innovative energy on higher and lower layers
 Where innovation thrives
Myth-4: A clean-slate architecture will lead to a better
future Internet than the evolution of the current
architecture

A clean-slate architecture in 2007, based on the current
economic/technological constraints, objectives, and requirements
will probably be irrelevant in 5-10 years from now



Clean-slate architectural research would have a chance if we knew
the actual objectives and constraints in 5-10 years from now


The environment in which a network architecture “lives” is changing
faster than the timescales of academic research
How long does it take to think, design, prototype, experiment,
publish and fund a complete clean-slate architecture? 5-10 years?
But we don’t have this luxury
On the other hand, evolutionary research does not need crystal ball



Focus on current objectives, constraints and problems
Provide evolutionary solutions that do not break existing net
Repeat as needed
A recommendation to NSF & the community

Embrace and support evolutionary research
 Evolutionary research does not mean “incremental patches”
or ad-hoc/easy research

An unfortunate misconception that has gone unnoticed
Evolutionary research has a high impact on the Internet and
to the broader society
Evolutionary research does not benefit from testbeds and
toy-prototypes



Instead, it needs Internet-based facilities such as:
 Distributed Internet monitoring & probing infrastructures
 Experimental ISPs with connections to real ISPs
 Experimental but production-level services (e.g., an NSFfunded YouTube-like service) that can attract real users to
instrumented facilities
If you are interested to read more..
 Paper under submission:
“What would Darwin think about GENI and FIND?
Evolutionary versus clean-slate Internet research”
 Email me for a copy