Re: [ncrg] New Draft: Network Complexity Framework

Luca Caviglione <luca.caviglione@ge.issia.cnr.it> Wed, 31 October 2012 12:14 UTC

Return-Path: <luca.caviglione@ge.issia.cnr.it>
X-Original-To: ncrg@ietfa.amsl.com
Delivered-To: ncrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75621F8490 for <ncrg@ietfa.amsl.com>; Wed, 31 Oct 2012 05:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjKQsdmOAAOE for <ncrg@ietfa.amsl.com>; Wed, 31 Oct 2012 05:14:58 -0700 (PDT)
Received: from smtpext.ba.cnr.it (aramis.area.ba.cnr.it [150.145.80.200]) by ietfa.amsl.com (Postfix) with ESMTP id 64BEF21F8489 for <ncrg@irtf.org>; Wed, 31 Oct 2012 05:14:57 -0700 (PDT)
Received: by smtpext.ba.cnr.it (Postfix, from userid 503) id C295327D802; Wed, 31 Oct 2012 13:14:57 +0100 (CET)
Received: from tesi1.ge.issia.cnr.it (tesi1.ge.issia.cnr.it [150.145.4.83]) by smtpext.ba.cnr.it (Postfix) with ESMTP id 8EA0527D801 for <ncrg@irtf.org>; Wed, 31 Oct 2012 13:14:56 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Luca Caviglione <luca.caviglione@ge.issia.cnr.it>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F567823@xmb-rcd-x14.cisco.com>
Date: Wed, 31 Oct 2012 13:14:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <21C12CB8-5ED0-46AC-96B3-4220D34784C1@ge.issia.cnr.it>
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F567823@xmb-rcd-x14.cisco.com>
To: ncrg@irtf.org
X-Mailer: Apple Mail (2.1499)
X-Mailman-Approved-At: Wed, 31 Oct 2012 05:30:21 -0700
Subject: Re: [ncrg] New Draft: Network Complexity Framework
X-BeenThere: ncrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Complexity Research Group <ncrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/ncrg>, <mailto:ncrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/ncrg>
List-Post: <mailto:ncrg@irtf.org>
List-Help: <mailto:ncrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/ncrg>, <mailto:ncrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2012 12:16:00 -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,
Luca 

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

> Complexity group, 
> 
> As promised a long time ago, finally I created a first draft of the framework document: 
> http://tools.ietf.org/html/draft-behringer-complexity-framework
> 
> 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
> ncrg@irtf.org
> https://www.irtf.org/mailman/listinfo/ncrg