Four myths about GENI (and one recommendation) Constantine Dovrolis dovrolis@cc.gatech.edu 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