Internet DRAFT - draft-papadimitriou-design-principles-evolution
draft-papadimitriou-design-principles-evolution
Internet Engineering Task Force D. Papadimitriou
Internet Draft Alcatel-Lucent
Intended Status: Informational B. Sales
Expires: November 22, 2012 Alcatel-Lucent
Th. Zahariadis
Synelixis
May 21, 2012
Internet Architecture Design Principles Evolution
draft-papadimitriou-design-principles-evolution-00
Abstract
The purpose of this draft is to extend RFC 1958 and RFC 3439
analysing the design principles that govern the Internet
Architecture, evaluate how then have evolved since they were
initially introduced and how we expect to evolve in the near future.
We describe a number of design principle, discuss their implications
on the Internet architecture, design and engineering.
The work has been based on the outcome of the ad-hoc European
Commission Future Internet Architecture (FIArch) group.
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 1]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 2]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . .. . . . . . 5
1.2 Abbreviations/Definitions . . . . . . . . . . .. . . . . . 6
2 Preserving certain design principles . . . . . . . . . . . . . 7
2.1 Heterogeneity support principle . . . . . . . . . . . . . 7
2.2 Scalability and the Amplification Principle . . . . . . . 8
2.3 Robustness principle . . . . . . . . . . . . . . . . . . . 9
2.4 Loose Coupling principle . . . . . . . . . . . . . . . . . 9
2.5 Locality Principle . . . . . . . . . . . . . . . . . . . . 10
3. Evidences for augmenting/adapting certain design principles . . 10
3.1 Keep it simple, but not "stupid" principle . . . . . .. . . 10
3.2 "Minimum Intervention" Principle . . . . . . . . . . .. . . 11
3.3 Robustness principle . . . . . . . . . . . . . . . . .. . . 12
3.4 Modularity & Adaptability Principle . . . . . . . . .. . . 12
3.5 Polymorphism principle (as extension to the modularity
principle) . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Unambiguous naming and addressing principle . . . . .. . . 14
3.7 Extending the end-to-end principle . . . . . . . . . .. . . 15
4. Conclusions - Evidences of emergence of new seeds . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 3]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
1 Introduction
The Internet is the most important information exchange means
nowadays. It has become the core communication environment, not only
for computers but also for sensors, as well as social and human
interactions. Yet, the immense success of Internet has increased the
demand for both performance and functionality to fulfill the needs
of, e.g. real-time applications, sensor/ad-hoc networks, and mobile
networks, but without guarantees that the Internet as we know it
today will be able to support them. These new demands and needs
combined with the continuous expansion of the Internet
(pervasive/ambient networks, vehicular networks, etc.) can up to a
certain degree be addressed by means of:
i) Capacity investment: incremental infrastructure investment, e.g.,
more and more bandwidth in wireline, wireless and mobile networks.
However, analyses have shown that increasing the bandwidth on the
Internet core network will not suffice due to new qualitative
requirements in, for example, highly critical services such as e-
health applications, clouds of services and clouds of sensors, new
social network applications like collaborative 3D immersive
environments, new commercial and transactional applications, new
location-based services and so on [Jacobson09] [Zahariadis11]; and
ii) Capability investment: incremental and reactive improvement of
Internet protocols (and when protocol extensions are not possible
complement them by means of overlays). For instance, the recent Real
Time Collaboration on the World Wide Web (RTC-Web effort) to achieve
a standardized infrastructure in Web browsers on which real-time
interactive communication between Web users shows that protocols hit
performance walls. Hence, these limits range well beyond the
classical routing and congestion control challenges of the Internet.
Hence, even if it is difficult to provide accurate timeline when
applicability of classical engineering practices and associated
solutions will reach their objective limits, the functional,
performance as well as the structural and quality properties that the
Internet architecture is expected to meet (but that cannot be
resolved with current or foreseeable paradigms), lead to rethink its
foundational principles.
This effort is conducted and documented in this I_D without pre-
assuming a specific architectural transformation path (evolutionary
or not). Design principles have played, are playing and will play a
central role in the architecture of the Internet by driving most
engineering decisions at conception time but also by operational
decisions of ICT systems at running time. With the term design
principles, we refer to:
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 4]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
i) a set of commonly accepted rules delineating how a designer/an
architect can best structure and organize the various architectural
components at conception time, and rules guiding, controlling and/or
regulating a proper and acceptable behaviour at running time, and
ii) a set of fundamental and time invariant laws describing the
underlying the working of an engineered artefact. Often cited as the
corner stone of the Internet design compared to architectures that
rely exclusively on modelling, design principles are not formally
defined using a closed mathematical formulation. Classical
telecommunication systems (i.e., legacy voice communication) do not
consider design principles and derive their model directly from
requirements.
When it comes to the design of the Internet, the formulation of its
principles is a fundamental characteristic that guides the
specification of its model. In analyzing the Internet design
principles and their evolution, we must remember that technical
change is permanent (not necessarily continuous) in the information
and communication domain: "in this environment, some architectural
principles inevitably change. Principles that seemed inviolable a few
years ago are deprecated today. Principles that seem sacred today
will be deprecated tomorrow. The principle of constant change is
perhaps the only principle of the Internet that should survive
indefinitely [RFC1958].
In this context, this I_D aims to review and analyse the application
of known design principles in today's and tomorrow's Internet
Architecture and evaluate their potential evolution. The proposed
analysis has been performed to minimize as much as possible the
subjective component that arises when dealing with architectural
evolution not derivable from closed mathematical formulation or
proof. Analogously to [RFC3439] the ultimate goal of this I_D is not
to lay down dogma about how Internet architecture and its underlying
protocols should be designed. Rather, it is to convey various
guidelines that have been found useful in conducting Internet-related
research, and that may be useful to those designing new protocols or
evaluating such designs. Finally, inline with the various
architectural efforts conducted in the last two decades, it also
invites the Internet community at large to initiate
investigation/analysis on new design principles that will potentially
drive the evolution of the Internet architecture.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 5]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
1.2 Abbreviations/Definitions
It is important to define the terms we have used in our work:
o "Architecture" is a set of functions, states, and objects/
information together with their behavior, structure, composition,
relationships and spatio-temporal distribution. The specification of
the associated functional, object/informational and state models
leads to an architectural model comprising a set of components (i.e.
procedures, data structures, state machines) and the characterization
of their interactions (i.e., messages, calls, events, etc.). Please
note that the canonical definition of architecture includes the
principles and guidelines governing their design and evolution over
time.
o "Data" to refer to any organized group of bits a.k.a. data packets,
data traffic, information, content (audio, video, multimedia), etc.
o "Service" to refer to any action or set of actions performed by a
provider (person or system) in fulfillment of a request, which occurs
through the Internet (i.e., by exploiting data communication, as
defined below) with the ultimate aim of creating and/or providing
added value or benefits to the requester(s). Services are the means
for users (organizations, public bodies, companies and people) to get
controlled access to the available data through the Internet.
o "Resource" is any logical or physical component that may be
uniquely identified. It may be service resource (e.g. a service
component, a service API), or infrastructure resources (e.g. CPU,
memory, network interface etc.)
o "Design principles" refer to agreed structural and behavioural
rules on how a designer/an architect can best structure the various
architectural components and describe the fundamental and time
invariant laws underlying the working of an engineered artefact.
o "Structural and behavioural rules" is a set of commonly accepted
and agreed rules serving to guide, control, or regulate a proper and
acceptable structure of a system at design time and a proper and
acceptable behaviour of a system at running time.
o "Time invariance" refers to a system whose output does not depend
explicitly on time (this time invariance is to be seen as within a
given set of initial conditions due to the technological change and
paradigms shifts, the economical constraints, etc.). Robustness and
longevity over time is a consequence of this time invariance.
o "Engineered artefact" is an object formed/produced by engineering.
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 6]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
One of the critical points that we have faced many times during our
analysis has been the term "complexity". There are multiple
definitions of the complexity. Within our analysis we have mainly
focus on the architectural and communication complexity. Moreover, we
define the following terms being used throughout this document:
o "Communication" the exchange of "data" (including both control
messages and "data") between a source and a sink.
o "Communication end-point" the physical or logical source and sink
of information. The communication end-point can be considered to be
an application, a service, a process, a protocol, a node, a network.
o "End-to-end communication" a communication that takes place between
communication end-points of the same physical or logical functional
level.
o "Module" is a unity that represents functions. It could be
considered as a physical or logical unity.
o "Security" is a process of taking into account all major
constraints. Security includes: Robustness, Confidentiality and
Integrity.
o "Robustness" is the degree to which a system operates correctly in
the presence of exceptional inputs or stressful environmental
conditions [IEEE-610].
o "Confidentiality" is the property of "ensuring that information is
accessible only to those authorized to have access" and is one of the
cornerstones of information security [ISO-27002].
o "Integrity" In literature there are multiple definitions of the
integrity. Here we consider mainly the "data integrity" and "system
integrity".
2 Preserving certain design principles
We start our analysis by highlighting design principles that apply to
current Internet and provide arguments why they should be preserved
also in the future.
2.1 Heterogeneity support principle
Since the early days of the Internet, heterogeneity is one of its
major characteristics. The Internet is characterized by heterogeneity
at many levels including: terminal/devices running TCP/IP stack and
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 7]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
intermediate nodes running routing function, scheduling algorithms
and queuing disciplines applied at intermediate nodes, multiplexing
of traffic (bufferless vs. elastic), traffic mix generated by a wide-
variety of applications, congestion control operated at multiple
spatial and temporal scales, and protocol versions and
implementations.
It is important to remember that IP (as network function) has been
designed as the common denominator among all data link layers
themselves relying on various physical medium enabling, e.g., point-
to-point (optical), multi-access (Ethernet) links. Heterogeneity is
also characteristic of the organic operation of the Internet that
comprises many autonomous organizations and service providers
reflected by a large heterogeneity of administrative domains, each
with their own separate policy (routing, traffic control, charging,
etc.). As a result, the heterogeneity principle is proposed to be
supported by design [RFC1958].
In the future, the heterogeneity is expected to be much higher than
today. Multiple types of terminals/hosts, multiple network nodes,
multiple protocols, and multiple applications will exist. Hence, the
capability to support heterogeneity should remain as one of the main
design principles.
2.2 Scalability and the Amplification Principle
The need to ensure scalability is of increasing importance.
Scalability refers to the ability of a computational system (hardware
or software) to continue to function (without making changes to the
system) under satisfactory and well specified bounds, i.e., without
affecting its performance, when its input is changed in size or
volume or in their respective rate of variation. Accounting for the
continuous expansion of the Internet (e.g., 10% annual growth rate of
the number of AS, 20-25% annual increase of the number of routes),
scalability is considered among the major general principles of the
Internet: "All designs must scale readily to very many nodes per site
and to many millions of sites" [RFC1958]. This principle refers thus
to the scale invariant that the global Internet design should meet.
Scalability is also closely related with the amplification principle,
which states that "there do exist non-linearities which do not occur
at small to medium scale, but occur at large scale" [RFC3439]. In
other words, "in many large interconnected networks, even small
things can and do cause huge events; even small perturbations on the
input to a process can destabilize the system's output", and "the
design engineer must ensure such perturbations are extremely rare"
[RFC3439].
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 8]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
The number of devices with Internet access (e.g., PCs, laptops, smart
phones), communication nodes (e.g., home, access, edge and core
routers), autonomous systems, applications in the Internet is
expected to significantly increase. Moreover, the direct
interconnection of sensor networks with the legacy Internet will
exponentially increase the number of Internet nodes. If one sees the
Internet currently comprising three level of tiers, extension of the
Internet at its periphery could expectedly lead to a fourth tier
which would have a fundamental impact on the properties of the
routing system. As a result, we believe that scalability is among the
major design principles that should govern the architecture of the
Internet, while the amplification principle would become more
prominent as the scale of the Internet increases.
2.3 Robustness principle
The robustness principle was based on the condition that each
protocol implementation must interoperate with other created by
different individuals. As there may be different interpretations of
the same protocol, each one should "be liberal in what you accept,
and conservative in what you send." The fundamental objective of this
principle was to maximize interoperability between network protocol
implementations, particularly in the face of ambiguous or incomplete
specifications. Focusing on the programmable part of the Internet
(being software or some programmable components), "Software should be
written to deal with every conceivable error, no matter how unlikely.
In general, it is best to assume that the network is filled with
malevolent entities that will send in packets designed to have the
worst possible effect" [RFC1122]. This assumption leads to suitable
protective design, although the most serious problems in the Internet
have been caused by un-envisaged mechanisms triggered by low-
probability events! In the future, the Internet is expected to
handle broader spectrum of applications including mission and time
critical applications, related with, e.g., health, energy, robotic,
transport/logistic (thus well beyond multimedia for entertainment).
As a result, part of the robustness principle that covers issues
related to minimizing the malfunction, uninterrupted operation and
interoperability, remains unchanged. As it is later analysed and
argued, the robustness principle should be extended/ adapted to
additional cover security issues.
2.4 Loose Coupling principle
Loose coupling appears to be a necessary condition for a well-
structured system and a good design as i) it simplifies testing and
troubleshooting procedures because problems are easy to isolate and
unlikely to spread or propagate, ii) combined with high cohesion, it
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 9]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
supports the general goals of high readability and maintainability,
and iii) it minimizes unwanted interaction among system elements. In
addition, tightly coupled systems are likely to have unforeseen
failure states and implies that the system has less flexibility in
recovering from failure states. For these reasons, this design
principle shall be preserved and even reinforced as a result of the
increasing importance of the availability objective [FIArch11].
Nevertheless, recent evolution shows that loose coupling can also
increase difficulty in maintaining synchronization among diverse
components within a system when a higher degree of element
interdependence is necessary. Hence, loose coupling is important but
it would be appropriate to consider that under stress conditions,
higher cohesion should be possible for proper functionality.
2.5 Locality Principle
The locality principle has played a very important role in computer
design, programming and the Internet the last decades. Following the
principles of spatial and temporal locality, recent computer systems
have pushed cache memory to higher levels in the computer systems but
the essence remains the same: reflect the chosen methods for using
the principles of spatial and temporal locality. In this context, the
principles of spatial and temporal locality will have to be extended
to distributed computing systems and to the higher layers space of
distributed application architectures. On the other hand, locality
will play a fundamental role in self- stabilizing distributed systems
by ensure sub-linear stabilization with respect to the number of
local system components and interactions among components.
Based on the above considerations, the locality principle plays an
important role and should be preserved, while its scope should be
extended to cover additional roles in distributed systems and
distributed application architectures.
3. Evidences for augmenting/adapting certain design principles
In this section we highlight design principles that have been
described and still apply to the Internet architecture. Yet, we
challenge that they should be adapted in order to address the
evolving design objectives of the Internet.
3.1 Keep it simple, but not "stupid" principle
As already explained, one of the main design principles of the
Internet was the approach to keep things simple (the term things
refers here in particular to protocols and intermediate systems). If
there were many ways to do the same thing, one should choose the
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 10]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
simplest one [KISS]. This common sense engineering principle
continued requirement to make the usage of network functionality
simple and robust, but more processing logic is needed in order to
achieve the expected functionality.
In Internet design, the complexity belongs at the edges, and the IP
layer of the Internet remains as simple as possible. Complex systems
are generally less scalable, reliable and flexible. Architectural
complexity implies that in order to increase the reliability it is
mandatory to minimize the number of components and their interactions
in a service delivery path, where the service delivery path can be a
protocol path, a software path, or a physical path. However, this
principle has already been challenged. Complex problems sometimes
require more elaborated solutions and multidimensional problems such
as the Internet architecture will be providing non-trivial
functionality in many respects. The general problem can be seen as
follows: complexity is a global measure of the architecture structure
and behaviour. In that respect, arbitrary lowering complexity (over
space) might result in local minimum that may be globally
detrimental. Hence, the challenge becomes to determine the best
placement and distribution of functionality that would globally
minimize the architectural complexity. In turn, scalability and
simplicity should be handled as strongly interconnected first
priority principles of the Internet architecture.
3.2 "Minimum Intervention" Principle
The principle of minimum intervention states that: "To minimize the
scope of information, and to improve the efficiency of data flow
through the Encapsulation Layer, the payload should, where possible,
be transported as received without modification" [RFC3439]. The
minimum intervention principle is critical to maintain and preserve
data integrity and to avoid useless intermediate information message
or packet processing.
Deep Packet Inspection (DPI), Network Address Translation (NAT) and
network coding provide three good examples of detrimental
intermediate in-band processing of packet flows (note: the two first
are also good examples of locally deployed artefact to selfishly
compensate delays in adoption of global solutions, e.g., IPv6).
Moreover, in some cases, it directly conflicts with the simplicity
principle and the complexity minimization principle; e.g., in
sensor/machine-to-machine and ambient/pervasive networks where
communication gateways (store-and-forward) and actuators meant to
enable communication between networks by offloading capabilities that
would be costly -or sometimes even impossible- to support on
sensors.
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 11]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
As a result, the minimum intervention principle should be relaxed to
enable wider-variety of intermediate processing at the necessary
condition it decreases global complexity.
3.3 Robustness principle
Over recent years, in order to increase robustness and system
reliability, some have advocated to transform this fundamental
principle from "be liberal in what you accept, and conservative in
what you send" into "be conservative in what you send and be even
more conservative in what you accept from others". However, adoption
of this approach would result into dropping a significant level of
interoperability between protocol implementation.
Nevertheless with respect to security, this design principle leads to
weak security architecture thus requiring adaptation. Indeed, "it is
best to assume that the network is filled with malevolent entities
that will send in packets designed to have the worst possible effect.
This assumption will lead to suitable protective design" [RFC1122].
Henceforth, we argue that the robustness principle should be adapted
to incorporate a self-protection structural and behavioural principle
(coordination of the local responses to external intrusions and
attacks including traffic, data and services trace back that would
enforce in turn accountability) as well as confidentiality, integrity
and authentication should be inherently offered to information
applications and service.
3.4 Modularity & Adaptability Principle
Current communication systems are designed as a stack of modules
structured by static and invariant binding between layers (modules)
that are specified at design time. Indeed, when they were developed
CPU and memory were scarce resources and the expected uniformity of
their utilisation (computing machine interconnection) lead to a
design optimizing the cost/performance ratio at design time.
Moreover, [RFC1122] also defines adaptability as a major design
principle: "Adaptability to change must be designed into all levels
of Internet host software. As a simple example, consider a protocol
specification that contains an enumeration of values for a particular
header field -- e.g., a type field, a port number, or an error code;
this enumeration must be assumed to be incomplete. Thus, if a
protocol specification defines four possible error codes, the
software must not break when a fifth code shows up." The second part
of the principle is almost as important: software on other hosts may
contain deficiencies that make it unwise to exploit legal but obscure
protocol features. A corollary of this is "watch out for misbehaving
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 12]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
hosts"; host software should be prepared, not just to survive other
misbehaving hosts, but also to cooperate to limit the amount of
disruption such hosts can cause to the shared communication facility.
Nowadays, looking at current evolution with i) repetition of
functionality across multiple layers, e.g., overlays that allow
carrying TDM over IP over Ethernet over IP/MPLS, emphasize the need
to define common patterns, monitoring modules repeated over multiple
layers (which then requires to recombine information in order to be
semantically interpretable) as well as security components each
associated to a specific protocol sitting at a given layer (which
result into inconsistent response to attacks), ii) as part of the
same layer, the proliferation of protocol variants all derived from a
kernel of common functions/ primitives, iii) the variability of
external and internal events that communication systems have to cope
with emphasize that the cost/performance objective to be met by
communication systems can vary over time (thus messages would be
processed by variable sequence of functions determined at running
time), iv) the increasing heterogeneity of environments where
communication systems are involved emphasize that some of these
functions may be more or less elaborated, and v) Increasing
heterogeneity of running conditions as well as increasing occurrence
of unexpected events leads to i) consider modules connected by means
of realization relationships that supply their behavioural
specification, ii) distinguish between general and specialized
modules (inheritance), and iii) enable dynamic and variable binding
between the different modules such that the sequence of functions
performed is specified at running time.
This being said, in the current architecture, the transport module is
not complete and thus not modular. Indeed the transport address
depends on the IP address and more generally its usage relationship
does exclusively depend on the existence of other modules in the
stack: one can't replace or use a TCP stack without knowledge of how
it will impact operations of other modules.
3.5 Polymorphism principle (as extension to the modularity principle)
Polymorphism (ability to take on different forms) in computer
science/programming space applies to data (generalized data type from
which a specialization is made) or functions (function that can
evaluate to or be applied to values of different types). It enables
to manipulate objects of various classes, and invoke methods on an
object without knowing that object's type.
The introduction of polymorphism principle is driven by the
motivation to make use of this fact to make our architecture simpler.
In many cases, the modularity and layering principles have been the
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 13]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
driving principles for both communication protocols and software
implementations. This principle has led to faster deployments, but
suboptimal solutions; as such these principles have been challenged
in many cases, especially in environments where functions of each
layer needs to be carried out completely before the protocol data
unit is passed to the next layer.
In this context, polymorphism enables to manage and operate first
class objects belonging to different kinds of classes (which within a
hierarchy often share common methods and attributes) while providing
the ability for a super-class to contain different objects of a
subclass type at different points in time. In turn, this allows i)
for objects of different classes to respond differently to the same
function call thus results in different functionality being executed
for the same method call, and ii) for run-time (dynamic) instead of
compile-time (static) binding.
Henceforth, the introduction of polymorphism would enable the same
abstract and autonomous loosely coupled components/objects to have
different functional and non-functional behaviour under different
environments or circumstances. The question remains open though as
how to parameterize these environmental variables and whether this
parametrization could be performed through distant exchanges
(remotely) which would turn this principle close to the concept
envisaged by active networks in the late 90's.
3.6 Unambiguous naming and addressing principle
As stated in [RFC1958], the Internet level protocol are and must
independent of the hardware medium and hardware addressing. This
approach allows the Internet to exploit any new digital transmission
technology of any kind, and to decouple its addressing mechanisms
from the hardware. It allows the Internet to be the easy way to
interconnect fundamentally different transmission media, and to offer
a single platform for a wide variety of Information Infrastructure
applications and services.
Concerning name and addressing, the following augmentations are
considered using [RFC1958] as starting point:
o Avoid any design that requires addresses to be hard coded or stored
on non-volatile storage. When this address this is an essential
requirement as in a name server or configuration server a discovery
process is recommended. In general, user applications should use
names rather than addresses. In that respect, the transport layer
address should be decoupled from any locator and use space invariant
identifiers associated to the communication end-point. In turn, this
would facilitate dynamic multi-homing, TCP connection continuity
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 14]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
(required for mobility) and more generally misuse of IP addresses.
o A single and common naming structure should be used.
o LOC/ID separation (initially proposed by the NIMROD effort):
resulting from the overload of IP address usage, upper layer
protocols must be able to determine end-point identifiers (ID)
unambiguously, and make use of locators (IP addresses) strictly for
end-to-end routing (processing at intermediate nodes) must be the
same at start and finish of transmission. This separation involves
the need to provide the capability for mapping (or resolving)
identifiers to locators at the end-points. Both Identifiers and
Locators must be unambiguous and be unique within any scope where
they may appear.
In the future, it is foreseen that not only the end-points (ID) and
their attachment points (LOC) need to be unambiguous and unique
within the scope in which they appear and are used, but also the
objects, e.g., data files/streams, software components, etc. At the
end, in most cases, the user is not willing to access a specific
server, but the objects that this server hosts or offers. If exactly
the same data (e.g. content, type, quality, security, etc.) and/or
associated service (i.e., functional and not functional matching) can
be provided in another way (e.g. from another server or method), it
is also acceptable and in many cases even preferable if the actual
quality is better (or cost lower).
Moreover, the current ID/LOC approach only deals with hosts and can
not provide a method to ensure that an entity is the one claiming to
be or, even worse, they disclose a fixed identifier that can be
easily traced by any other network element to know the operations
that an entity performs, thus violating its privacy.
In near future, naming and addressing as a design principle should be
extended to unambiguous identify hosts, resources, data, services.
3.7 Extending the end-to-end principle
Historically, the "end-to-end principle" has been one of the most
controversial issues in the Internet innovation. Many experts in the
area insist that the "end-to-end" principle is still valid as it
applies as the communication is divided at autonomous legs. However,
the clear definition of communication end-points becomes more and
more complex to delimit, as middle boxes and application layer
gateways are deployed at the edges of networks.
AAnother challenge concerning this principle is that IP overlay
applications such as IP multicast and mobile IP (MIP), require that
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 15]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
specific functionality (RP in ASM, and Home Agent in MIP) is
supported and provided by (at least some)intermediate nodes. It is
important to notice though that some of these functions and their
spatial location (in the end-to-end communication chain) are purely
driven by arbitrary choices, e.g., Proxy MIP for mobility management
or delayed migrations, e.g., NAT instead of rolling out IPv6. Another
challenge comes from the Internet of Things/Smart objects
communication, where the end-to-end communication may be
significantly modified by intermediate gateways and sensor networks
sink nodes.
It is also well perceived that for many modern applications (e.g.
mobile applications, distributed searching, certain aspects of
collaborative computing) maintaining state information within the
network may now be desirable for efficiency if not overall
performance effectiveness. To argue today that the only stateful
elements that may be active in the Internet environment should be
located at the edges of the Internet is to ignore the evolution of
software and other technologies to provide a host of services
throughout the Internet [WGIG04].
Finally, as stated in the [FIArch] and further analyzed in [RFC6077],
support of congestion control cannot be realized as a pure end-to-end
function: congestion is an inherent network phenomenon that in order
to be resolved efficiently require some level of cooperation between
end-systems and the shared communication infrastructure. Instead of
placing specific functions in specific positions either at end
systems or on routers in the network core, these functions must be
allowed to be deployed anywhere they are needed [RFC3234].
As a result, we believe that motivations to "update" or augment this
principle increase; however even if this principle is challenged, due
to the heavy consequence in terms of scalability, survivability and
robustness on the Internet at large departing from this principle
remains open.
4. Conclusions - Evidences of emergence of new seeds
In this draft, we have analyzed the evolution of existing design
principles and evaluate their potential evolution. From this
analysis, we have determined through qualitative but also (and when
available quantitative arguments) the design principles that should
be preserved, adapted or even augmented.
Yet, evidences show that the Internet (and its architecture)
progressively evolves from a pure network architecture to an
ecosystem interconnecting resources of any type(forwarding, computing
and storage and/or their combination) and any type of content or
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 16]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
information and be extended to even socio-economic dimensions.
Realising such Internet Architecture ecosystem involves new design
principles that go well beyond the networking primitives. In this
context, new design principles will progressively appear and shape
the evolution of the Internet Architecture. However, before being in
a position to formulate such principles, one has to explore a
multitude of seeds proposed by various architectural work and efforts
conducted during the last two decades (some of which are documented
in [Papadimitriou12]). A seed for a new design principle refers to a
concept or a notion at the inception of a well formulated design
principle. The term seed acknowledges that i) formulating principles
is a complex exercise, ii) research is still ongoing in proving their
value and utility (some of our analysis and exploitation of research
results may not be mature enough) but also their impact, and iii) the
proposed seeds may not be flourishing (a lot of proposal came in and
very few will materialize).
The risk is not negligible though that without well formulated and
commonly accepted design principles, evolution might lead to hamper
the commonality and the genericity of a system that is inherently de-
centralized but also organically participative. We consider thus that
initiating systematic investigation/analysis on new (seeds of)
becomes crucial as the diversity of protocol design choices and
decisions in such environment (that would combine more dimensions
than network connectivity functionality) becomes such that it may
even non-voluntarily harm interoperability
5. Acknowledgements
This draft has been based on the work from the EC Future Internet
Architecture (FIArch) group. The work leading to these results has
received funding from the European Union's Seventh Framework
Programme (FP7/2007-2013) by a number of projects, including FP7-ICT-
COAST, FP7-ICT-REVERIE, FP7-ICT-EINS, and FP7-ICT-EULER.
6. References
[Clark05] D.D. Clark, J. Wroclawski, K.R. Sollins, R. Braden, Tussle
in Cyberspace: Defining Tomorrow's Internet. IEEE/ACM Trans.
Networking, Vol.13, Num.3, pp.462-475, June 2005.
[Clark88] D.D. Clark, The design philosophy of the DARPA internet
protocols, ACM SIGCOMM Computer Communication Review,
Vol.18, No.4, August 1988, pp.106-114.
[Conti04] M. Conti, G. Maselli, G. Turi, and S. Giordano, "Cross-
Layering in Mobile Ad Hoc Network Design," IEEE Computer,
Special issue on Ad Hoc Networks, February 2004.
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 17]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
[Dening05] Peter J. Denning, The locality principle, Communication
of the ACM, Vol.48, No.7, July 2005, pp.19-24.
[Feldman07] A. Feldman "Internet Clean-Slate Design: What and Why?"
ACM SIGCOMM Computer Communications Review, Vol.37, No.3,
July 2007, pp.59-64.
[FIArch11] EC FIArch Group, "Fundamental Limitations of current
Internet and the path to Future Internet," March 2011.
[Fogel66] L.J. Fogel, A.J. Owens, M.J. Walsh, Artificial
Intelligence through Simulated Evolution, John Wiley,
1966.
[Goldsmith02] A.J. Goldsmith, S.B. Wicker, "Design challenges for
energy-constrained ad hoc wireless networks," IEEE
Wireless Communications Magazine, Vol.9, No.4, 2002,
pp.8-27.
[Haapola05] J. Haapola, Z. Shelby, C. Pomalaza-Raez, P. Mahonen,
"Cross-layer energy analysis of multi-hop wireless sensor
networks," 2nd European Workshop on Wireless Sensor
Networks (EWSN), Istanbul, Turkey, 2005.
[Hakala06] I. Hakala, M. Tikkakoski, "From vertical to horizontal
architecture - a cross-layer implementation in a sensor
network node," InterSense'06, Proc. of 1st International
Conference on Integrated Internet Adhoc and Sensor
Networks, Nice, France, May 2006.
[Hilborn04] R. Hilborn, "Sea gulls, butterflies, and grasshoppers: A
brief history of the butterfly effect in nonlinear
dynamics", American Journal of Physics, Vol.72, No.4,
pp.425-427. Bibcode 2004, doi:10.1119/1.1636492.
[IEEE-610] IEEE Std 610.12.1990 - IEEE Standard Glossary of Software
Engineering Terminology.
[ISO-27002] International Organization for Standardization (ISO),
"Information technology. Code of practice for information
security management," ISO 27002, 2005 (replaced ISO-17799).
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 18]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
[Jacobson09] V.Jacobson, D.Smetters, J.Thornton, M.Plass, N.Briggs,
R. Braynard, "Networking Named Content," Proceeding
of ACM CoNEXT 2009. Rome, Italy, December 2009.
[Johnsson03] K.B. Johnsson, D.C. Cox, "An adaptive cross-layer
scheduler for improved QoS support of mixed data traffic
on wireless data systems," in: Vehicular Technology
Conference, 6-9 October 2003, pp.1618-1622.
[Kempf04] J.Kempf, Ed., R.Austein, Ed., "The Rise of the Middle and
the Future of End-to-End: Reflections on the Evolution of
the Internet Architecture", IETF, RFC 3724, March 2004.
[KISS] "Keep it Simple Stupid". The Jargon File, version 4.4.7.
[Liu05] Y. Liu, H. Zhang, W. Gong, D. Towsley "On the Interaction
Between Overlay and Underlay Routing," Proc. IEEE INFOCOM
2005.
[Papadimitriou12] D. Papadimitriou, Th. Zahariadis, P. Martinez-Julia,
I. Papafili, V. Morreale, F. Torelli, B. Sales, P.
Demeester, "Design Principles for the Future Internet
Architecture", Lecture Notes in Computer Science, Vol.7281,
May 2012, pp.55-67.
[Prasad08] R. Prasad "A Perspective of Layerless Communications,"
Wireless Personal Communications, 2008, pp.95-100.
[RFC793] J. Postel, "Transmission Control Protocol", IETF, RFC 793,
September 1981.
[RFC1122] R. Braden, Ed., "Requirements for Internet Hosts --
Communication Layers", IETF, RFC 1122, October 1989.
[RFC1631] K. Egevang, P. Francis, "The IP Network Address Translator
(NAT)," IETF, RFC 1631, May 1994.
[RFC1925] R. Callon, "The Twelve Networking Truths," IETF, RFC
1925, April 1996.
[RFC1958] B. Carpenter, "Architectural Principles of the Internet,"
IETF, RFC 1958, June 1996.
[RFC2775] B. Carpenter, "Internet Transparency", IETF, RFC 2775,
February 2000.
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 19]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
[RFC3234] B. Carpenter, "Middleboxes: Taxonomy and Issues," IETF,
RFC 3234, February 2002.
[RFC3439] R. Bush, D. Meyer, "Internet Architectural Guidelines,"
IETF, RFC 3439 (updates RFC 1958), December 2002.
[Saltzer84] J.H. Saltzer, D.P. Reed, and D.D. Clark, "End-To-End
Arguments in System Design", ACM Transactions on Computer
Systems (TOCS), Vol.2, No.4, November 1984, pp.277-288.
[Stevens74] W. Stevens, G. Myers, L. Constantine, Structured Design,
IBM Systems Journal, Vol.13, No.2, 1974, pp.115-139.
[WGIG04] "The End-End Principle and the Definition of Internet",
Working Group on Internet Governance (WGIG) Contribution
of Corporation for National Research Initiatives.
Prepared by: Patrice A. Lyons, November 10, 2004.
[Willinger02] Walter Willinger and John Doyle, "Robustness and the
Internet: Design and evolution", 2002
[Zahariadis11] Th. Zahariadis, D. Papadimitriou, H. Tschofenig, S.
Haller, P. Daras, G. Stamoulis, M. Hauswirth, "Towards
a Future Internet Architecture," Book Chapter, "Future
Internet Assembly," Lecture Notes in Computer Science,
Vol.6656, Springer, 2011, pp.7-18.
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 20]
Internet Draftdraft-papadimitriou-design-principles-evolution-00May 2012
Authors' Addresses
Dimitri Papadimitriou
Bell Labs, Alcatel-Lucent, Belgium
EMail: dimitri.papadimitriou@alcatel-lucent.com
Bernard Sales
Bell Labs, Alcatel-Lucent, Belgium
EMail: bernard.sales@alcatel-lucent.com
Theodore Zahariadis
Synelixis, Greece
EMail: zahariad@synelixis.com
D. Papadimitriou,et.al.Expires November 22, 2012 [Page 21]
