Four myths about GENI (and one recommendation)

1. Four myths about GENI (and one recommendation) Constantine Dovrolis dovrolis@cc.gatech.edu College of Computing Georgia Tech

2. 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

3. 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? • What happened to IPv6, IntServ, IP Multicast, and so many other architectural proposals? • 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 • 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

4. 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 • 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 • 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 • 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

5. 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

6. 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 • 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? • Clean-slate architectural research would have a chance if we knew the actual objectives and constraints in 5-10 years from now • 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

7. 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 NSF-funded YouTube-like service) that can attract real users to instrumented facilities

8. 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