Re: [ncrg] New Draft: Network Complexity Framework

Luca Caviglione <> Wed, 31 October 2012 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C165F21F8592 for <>; Wed, 31 Oct 2012 05:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GdiLDOCPgOgT for <>; Wed, 31 Oct 2012 05:18:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D1A821F8589 for <>; Wed, 31 Oct 2012 05:18:08 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD39B53B36 for <>; Wed, 31 Oct 2012 13:18:06 +0100 (CET)
X-Virus-Scanned: by
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id qLVtkCervfHa for <>; Wed, 31 Oct 2012 13:18:06 +0100 (CET)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 8BA9C53AB9 for <>; Wed, 31 Oct 2012 13:18:06 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Luca Caviglione <>
In-Reply-To: <>
Date: Wed, 31 Oct 2012 13:18:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "" <>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [ncrg] New Draft: Network Complexity Framework
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Complexity Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Oct 2012 12:18:09 -0000

Dear Michael,
thank you for the draft.

My 2 cents too:

1) Network classification is tightly coupled on the duties of the network itself. For instance, one might imagine to classify
network according to the access/core paradigm. Access networks should be quite independent (i.e., they must do not account
for un-predictability according to the draft), but they can show emergence (i.e., adding a large access network - which is a small
local variation in the overall topology - could severely impact over the core network, e.g., injecting a huge load). 

2) Even if layering does introduce "information hiding",  calculating complexities and properties without a clear separation 
could be misleading. If the hypothesis of "let's engineer a network for N duties" (with N quite bounded), analyzing the layers could
give you more information. Specifically:

-) do we need QoS (classes, templates, states, operators)? How the QoS is managed (MPLS could simplify if compared against 
IP/ATM or IP/DiffServ/IntServ models)? 

-) which kind of services is the network running? Self organization at one layer (at the application/transport for the 
p2p file-sharing case) does not take into account the underlying topology. Thus, you have the virtual network struggling against the
physical one and vice-versa. Self-organization enables to reacts quickly against churn, but it has catastrophic consequences
in case of well-planned attacks (it is especially true in case of super node p2p architectures).
An attack can also be the failure of a router or a link in the network, making the overlay unstable, or
needing reconfiguration (which typically generates high load). 

-) for the classification purposes (especially to produce the problem space), you could also considering the network as a graph. 
In this case, you have a space generated by (Nodes, Topologies, Protocols). 
Nodes give you the dependencies, and the configuration. 
Topologies give you idea on link and how they are arranged. 
Protocols give you hints on the service. 
One might refine the concept, i.e., (nodes, links, protocols), with the sub-space (nodes, links) generating the graph. Alas,
this is not elegant, since topology is a consequence of nodes and protocols at a given layer. In the case of p2p DHT, 
you can have a chord-DHT resulting in a ring topology (L4) over a physical network being completely different. The spanning tree
concept is again similar, where you create a topology according to protocols. 

Best Regards,

Il giorno 15/ott/2012, alle ore 18:46, Michael Behringer (mbehring) <> ha scritto:

> Complexity group, 
> As promised a long time ago, finally I created a first draft of the framework document: 
> Please note that this document is VERY draft. It needs a lot of additions, references to existing research, etc. There is a lot more existing material that should be referenced. I didn't have the time to do this before the deadline, and would indeed be very happy if some people would step forward and help make this document more complete. 
> If you can help (as a co-author) to make this document valuable, please shout! :-) 
> Any comments, suggestions, references, please reply-all! 
> To be discussed in our meeting on the 5th of November. 
> Michael
> _______________________________________________
> ncrg mailing list