Discussions about the Future Internet challenges are going all over the world in different groups belonging to commercial, regulatory and academic world with an aim to define and envisage the nature of and the process of arriving at the Future Internet. One of this group consisting of U.S and E.U based expert members of ISOC chapters or IETF working groups are working within the think tank that has been set up by the European FP7 project EIFFEL (www.fp7-eiffel.eu). Recently, on July 13th the group has issued a white paper identifying three main areas and challenges of the Future Internet: technology, business and society.

The overall aim of the whitepaper is to stimulate focussed debate on desirable research and regulatory goals, actions to be taken in reaching them, and potential barriers to their realisation. The main debate is set up within the Future Internet wikipedia that is located at www.fipedia.org/fipedia. The main findings, presented very briefly here, are intended to be used for further focussed debate on desirable research and regulatory goals, actions to be taken in reaching them, and potential barriers to their realisation.

The whitepaper that can be found at www.eiffel-thinktank.eu first discusses the assumption about the Future Internet and states that:

Future Internet Research is needed. This seems to be a foregone conclusion, given the numerous initiatives around the globe. But, precisely because of that diversity, it is unclear whether the term Future Internet research is meaningful in its own right, is a simple statement of the fact that there is a need to move on from where we are, or is simply a label attached to proposals as a means of securing funding. This report outlines some of the problems of the current Internet that have been recognized by a variety of initiatives in the community. Moreover, it discusses potential missed opportunities, since a myopic focus on problem solving may lead to lost opportunities of much broader scope. The second assumption states that:

Future Internet Research is possible. It is assumed that large scale Future Internet research programmes are capable of delivering strategic research that addresses concerns beyond those of immediate problem fixing. Such a view relies on the fact that it is possible to identify the most profound research directions, that it is possible to conduct scientifically valid research within them, and that the funding regime encourages the honest exploration of operational boundaries – encourages the because research funding given in small parcels can be innovative but may suffer from a lack of results in scale since such experiments are expensive to conduct, and large parcels of research funding that are capable of conducting large scale experiments (a) can only conduct relatively few such experiments; (b) are too expensive to ‘fail’, so tend to be low-risk and (c) in any case suffer from the fact that the use of the Internet changes once technology is deployed, often in ways that are not predicted by the technology designers.

However the main question to be answered is How will the Future Internet will happen? This is, however, difficult. Unlike the current Internet, which evolved from a small-scale research network, it is likely that the Future Internet would follow from the large-scale deployed system that already permeates many fibres of society and on which people rely. It therefore seems natural to emphasize a focus on the right mechanisms to ensure a continuous and fruitful evolution of this existing system towards a future one, whilst retaining an ability to sustain and foster innovation. The proper interplay of all interests, i.e., that of researchers, corporations, community groupings and governments, is crucial for success. This directly affects the style we as researchers use to conduct research, posing questions on how to engage with stakeholders and on how to embed processes of market selection and government control into the development of solutions by allowing the expression of such concerns in the runtime of the system rather than at design time. Equally importantly, the evaluation of the efficacy or significance of proposed solutions must, in the ultimate, be conducted in the context of the whole stakeholder base with particular attention paid to the impact it may have on society.

Challenges to Face

In looking for an answer to this question, the white paper identifies the big challenges that need to be addressed:
• Resilience, failure tracking & management: how do we increase the speed with which the Internet heals, providing larger resilience and ease management?
• Availability & robustness to attack: Proper architectural support to address the root means of various forms of attacks is needed, but there is no consensus between the contending partial solutions.
• Information security scalability: The Internet is designed so that information security can be built over it, end-to end. So this is seemingly not an Internet architecture problem although a holistic view on information security would demand for architectural solutions since the lack of globally scalable information security techniques does hold back evolution of new developments over the Internet.
• Resource accountability: At present, network operators are deploying boxes to limit or block communication with certain users or by certain applications. Without architectural support, their attempts to identify free-riding are largely arbitrary.
• Scaling for more extreme dynamics: The dynamic range of the Internet architecture is hitting its limits. Architectural solutions, for instance, for enabling the current inter-domain routing system to meet new extreme dynamics, are required.

System Evolution in a Faster Evolving World

The think tank is of the opinion that the changes must be laid down by applying evolutionary mechanisms. In a case of a large-scale system as the Internet the evolution must be carried out as a gradually developing process. This evolution of the system is particularly important considering the evolution of society due to the impact of the very system itself. In order to understand the suitability of the system to evolve, we need to understand the dynamics forcing the changes and devise an architecture that is suited for these dynamics to commence in runtime. These dynamics will need to define the required stepsize in evolution that is being necessary and therefore the changes in the underlying architecture that are being required.

In addition, there is a need to accept the fact that the scope of the dynamics affecting change of the Internet is widening. The Internet has become more than a technical artifact – it has transformed from a network for geeks to a crucial infrastructure used in society and business. Its impact on these areas is obvious, from e-commerce to e-government, the change in the perception of privacy to many other societal changes since its introduction. The virtual and the real world abide to similar rules regarding human rights and respect for personal space as guiding principles. Hence, the question of evolving the Internet is not a mere technical one anymore.

As well we need to consider that the evolution speed is increasing with the advances of technology. While the dynamics of an industry in which functions (and control) can be shifted in real-time still need to be understood, such increasing speed of dynamics is well-observed. We have already seen that the Internet’s evolvability becomes compromised when the architecture does not allow legitimate concerns to be expressed after its original design. As a result, people solve their problems in ad hoc ways, adding carbuncles in violation of the original architecture. Then subsequent requirements are even more difficult to satisfy, because of all the feature interactions with the plethora of exceptions to the original architecture.

The root of this problem lies deep in the processes that we use to design architectures and solutions. Much emphasis is placed on the design phase of the architecture, with requirements phases and use case definitions, accompanied by processes of standardization. This, inevitably leads to an emphasis of the concerns that are important to the players who are deeply involved in this phase while often neglecting the concerns of the actors entering the scene after the solution has been fixed. This Newtonian-Descartian concept of system design, relying on such requirements and use case definition phases, assumes the ability to capture all relevant concerns and therefore resolve the most probable run-time tussles at design time. The widening scope of the Internet beyond mere technology and the observed increase of ad-hoc solutions to concerns of actors after the design of the original architecture bring this design process into question. An understanding of what had been good in the current architecture and what needs to change to cater to the future must be agreed. In our rush for change however, we must not lose what was good about the previous architecture—we must be able to recognise a baby in the bath water. No good reason has been articulated for why all the original design principles should not still stand. But we must be open for understanding how we can establish architectural design processes that allow evolution towards the future requirements without delaying the progress of that evolution innecessarily. Hence, we must strive for a culture of design that results in designs that are founded on the (empirically successful) past but that nevertheless allows for a future that is characterised by change.

Networking Research as an Engineering Undertaking

As stated by Petroski, "Engineering has at its principal object not the given world but the world that engineers themselves create". Physicists study a given world to find out how it works. In contrast, network researchers started by first building networks. Networking research is all about what is the best design and how to build best networks, for whatever the definition of "best". But what is “best”? And how can we engineer systems that are “best” for a metric at some point without requiring a full re-engineering for another set of metrics of what “best” means for changed set of stakeholders.

How do we find out the best network design? We can look back into the early days of networking to look for clues. Around the late 60's and early 70's, the network and computing research community as a whole designed,implemented, and operated ARPAnet first hand. The fact that we designed a network does not lead to the conclusion that we fully understand how it works. We build networks by specifying individual components and we specify a protocol in a static way, which does not lead to a description of the dynamic, collective behaviour of multiple components when they interact through protocols. Furthermore, multiple protocols (in fact, a large number of them) exist in the system and we do not know how to derive the combined behaviour out of the interactions among various pieces. Thus after the engineering phase (or even parallel with the engineering design), network researchers have to take on the role of a scientist to understand the world we just built. We need to rigorously follow a set of well established scientific research methodologies to guide our process and procedures in exploring and understanding the results of our own design. This includes examining (and hopefully understanding) the emerging behaviours that we probably could have not understood before the design. But it also includes the ability to properly observe the phenomenon, which occur in daily operation. For that, an inherent ability is required to measure relevant data in the system. Judging the relevance of data to be measured, however, is often a challenge, given the (often) unclear nature of (future) observations. To summarize, we believe that the network research community must collectively play a double role in advancing the technology. We first design systems as engineers. We then study the artefacts as scientists. Our scientific findings are then fed back into the design or revision phase. This cycle continues and never ends.

For interested readers: please download the full article from www.eiffel-thinktank.eu