Subject: [ncrg] New Draft: Network Complexity Framework

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 15 Oct 2012 16:46:42 +0000

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

---

From: Rana Sircar <[email-masked]>
Date: Sun, 21 Oct 2012 22:05:34 +0530

Hi Michael,

Thanks for the very nice Draft. The Draft is quite informative &
thought-out.

Here are my 2 cents:
• As I have experienced, today networks can be classified into Telecom &
Enterprise ones. Most of the large networks are Brown-field networks & to a
lesser % we have Green-field scenarios. This is well covered in the Draft,
where you talk of backward compatibility. That apart, networks have also
got to be differentiated based on Access (Radio or Cable or mix) or Metro /
Core & Signaling. This is important since the Constraints & Design goals
are very different for each & thereby the complexity.
• Requirements for Network Design is typically the first stage. Based on
requirements the projects are undertaken. The next obvious stages are
Architecture, Planning, Design, Implementation & Operations / Management.
Complexity plays an important role at all these stages. Ability to measure
Complexity or put some order to it is important.
• This brings in an important measure of complexity in any network –
Interfaces – number of interfaces and or the types of interfaces. Consider
a hypothetical scenario - A completely homogeneous network that is almost
Plug & Play. This would be the simplest to Architect, Implement & maintain.
The other ends of the spectrum are the networks where everything changes
dynamically all the time.
• You do mention ”Good, Fast, Cheap”, but from Complexity perspective Good
becomes a bit difficult to measure – How Good is Good or Or Bad is it. This
was written in 1996. In 2012, many technologies are already commoditized
and as any PM would mention, Scope should play a big role. So, no wonder
that the PM looks at Scope, Cost & Time.

I noticed that you are open to co-authors. I am not sure if you would
accept me as a co-author since I am between jobs. But needless to say, I
would be very keen to contribute, if allowed.

Best Regards,
Rana Pratap Sircar
GSM+919899003705|

On 15 October 2012 22:16, Michael Behringer (mbehring)
<[email-masked]>wrote:

> 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.
>
> _______________________________________________
> ncrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/ncrg
>

---

From: Luca Caviglione <[email-masked]>
Date: Wed, 31 Oct 2012 13:18:04 +0100

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

---

From: Luca Caviglione <[email-masked]>
Date: Wed, 31 Oct 2012 13:14:50 +0100

Dear Michael,
thank you for the draft.

My 2 cents too:

Best Regards,
Luca