Future of internet in technology Essay

Proposing new technologies for the future Internet involves testing these technologies beforehand. Although theory, simulation, or emulation can be useful tools in the design process, experimentation with the “real” Internet is necessary to test a protocol’s reaction to unexpected, real events

that evade simulation or emulation. The Internet is now an

important production and business tool. ISPs would not

risk taking it down to install new, untested routing software

or risk running experimental software. Such an interruption

or an unexpected failure that could take the whole network

down could result in loss of a large number of existing business and resulting revenue. Thus, extensive experimentation

is a crucial step for coming even close to convincing an ISP

to deploy any new enhancement. On the other hand, deployment of the new technology might actually be the only way

of testing it, under “realistic” conditions. These two facts

create a vicious circle, where disruptive technologies are not

deployed due to lack of enough experiments to prove that

they would not harm deployed Internet services, and new

protocols can never be tested to the extend necessary due

to the ISPs’ averting to deploy them.

To overcome this deadlock, global experimentation platforms like PlanetLab [10] have been deployed with a goal of

allowing researchers to (i) conduct large scale experiments

in a “real” Internet topology and with “real” Internet traffic, while (ii) not disrupting the Internet’s regular behavior

and performance. PlanetLab is an open, overlay network

of “virtualized” computing and communication resources",

that are connected through the Internet. By using virtualization software like VINI [13] it allows different experiments

to share a large set of these resources by allocating dedicated

“slices” or resources, while at the same time being exposed

to real Internet events and traffic. Of course, when setting

up testbeds and doing virtualization, both full realism in

experimentation and reproducibility of experimental results

may not always be achievable. Researchers will have to hit

the right tradeoff between experiments that take into account real traffic and network conditions, and experiments

that can be reproduced, or at least provide enough context

to be meaningful for comparison.

Another effort towards that direction is XORP (eXtensible Open Router Platform) [15, 5]. XORP is an open software project that aims at allowing experimental networking

software to run side by side with production software. It

runs a virtual router stack on commodity PCs or servers",

and is also used by the VINI platform. Through a carefully

designed Forwarding Engine Machine (FEM) the forwarding

tables are exposed to a large number of concurrently running

routing protocols like OSPF, RIP, BGP, multicast protocols

like PIM, as well as experimental protocols under testing.

Each of these protocols runs as software on the user plane

to enable better (sandbox) isolation and security. What is

more, groups (or each) of these could run in a separate physical router. Thus, if multicast fails, for example, it would

not at least bring down the unicast service. Furthermore, if

one router is compromised by say a “router worm”, this software isolation could prevent its further spread (something

that is not guaranteed by today’s Internet routers). Finally",

this stack enables individual changes to the routing software

to be implemented much more easily and quickly. In other

words, XORP promises to deliver stability for the provider

and flexibility for deployment.

As with any virtualization approach, XORP may face performance considerations. It introduces an extra processing

layer (FEM) and its respective processing overhead. A PC

cannot be faster than specialized hardware. On the other

hand, the technology of XORP could allow many cheap

routers to be put together in a much more powerful router

cluster. It has been demonstrated that XORP can “virtualize” up to 40Gbps connections. Nevertheless, it is still

mostly envisioned to address “edge” routers rather than

“backbone” ones. Finally, XORP may also be used inside generic virtualization software like VINI, to allow different experiments/ISPs to run different routing protocols.

While XORP may sound like slow software, compared to the

fast specialized hardware found inside today’s routers, it is

claimed that in a high performance server it can support

routing at bandwidths up to 40 Gbps.

Taking virtualization a step further, one could even envision different Internet architectures, rather than just experiments, to be running side by side. One such proposal, called

CABO (Concurrent Architectures are Better than One) [14]",

advocates to separate the providers of the physical network

infrastructure from the service providers themselves. Despite a large economy running over the “net”, its economic

incentives are misaligned, stifling growth. Different ISPs

control different, often small parts of the network, and are

rarely on both ends of an end-to-end session. To change

anything in the core functionality of the protocols, and offer a new service, a number of different ISPs need to come

to agreement and coordinate to make anything happen. In

addition to the inherent difficulty of such an endeavor, this

also creates a disincentive for ISPs to compete by innovating.

How can an ISP attract customers from another ISP by creating and offering a better service, when that service often

requires the agreement of that second ISP in order to work?

For example, imagine an ISP wishes to offer QoS guarantees

to its customers. Even if it invests a lot of resources into developing its own network with QoS provisions, these would

be useless as soon as its traffic would have to traverse other

networks that do not comply.

CABO aims at better aligning these economic incentives.

A service provider would now lease physical resources endto-end from different infrastructure providers, and would be

able to offer a better service to its customers. Furthermore",

different service providers would not only have the ability

to, but now also every incentive to evolve, improve, and innovate their (virtual) network, in order to attract customers

to connect through them. Of course, this does not preclude

an entity from being both the infrastructure and service

provider in some cases, as for example when the national

infrastructure provider (e.g. France Telecom) also acts as a

service provided (e.g. for DSL).

However, this would imply that different service providers

would now have to share physical resources. Hence, some

means is necessary (i) to be able to guarantee each the required resources to operate its services, and (ii) to isolate

How to cite this essay: