Subject: [ncrg] Meeting Notes from Today's NCRG Call

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 14 May 2013 15:29:51 +0000

Attendees: Sheng Jiang, Xin Sun, Rana Sircar, Vladimir Marbukh, Michael Behringer (notes)

Subject: Evolving the NCRG framework draft

Brief notes: 
-	Suggestion to include metrics and tradeoffs in the framework draft; this was presented in Paris. 
-	draft-retana suggest more metrics, and trade-offs, these should also be in the framework draft. 
-	Sheng: Does cost (for example) represent a good metric? 
-	Cover the aspect of complexity: user facing? Internal, eg s/w complexity? 
-	Include text to describe the various forms (?) of complexity
	+ Operational complexity
	   deployment complexity; configuration complexity, trouble shooting
	+ Network system complexity
	  s/w complexity; h/w complexity; Protocol / algortihm complexity
	+ Management system complexity
	  OSS systems, etc.
-	Intrinsic complexity of the system vs complexity from the user base?
-	Rana: Should we limit to layer 3 and above? Or cover optical, wireless, etc? We may want to explain in the scope that the doc doesn't want to be specific to a particular solution/layer. 
-	Rana: Cost is a very good metric to measure complexity. 
-	Xin: Could improve 3.2: define different types of complexity. (operational complexity, s/w complexity, 
-	Vladimir: participated in a Santa Fe Complex Systems Institute workshop on network complexity; will point us to it. Also a recent Nature article. He could present to the group about these findings in Berlin. 

Next steps: 
-	propose on the list what you would like to contribute to the draft, or how it should be changed. 
-	set up bi-weekly calls to make progress on this. 

Thanks all for the discussion! 
Michael

Recording: 
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=68212117&rKey=eac0f0696ce0d40c

---

From: David Meyer <[email-masked]>
Date: Tue, 14 May 2013 16:31:28 +0100

Again, sorry all for missing the call; calendar skew from PDT to CET. --dmm

On Tue, May 14, 2013 at 4:29 PM, Michael Behringer (mbehring)
<[email-masked]> wrote:
> _______________________________________________
> ncrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/ncrg

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 14 May 2013 16:44:47 +0000

On 5/14/13 11:29 AM, "Michael Behringer (mbehring)" <[email-masked]>
wrote:

Hi!

>Attendees: Sheng Jiang, Xin Sun, Rana Sircar, Vladimir Marbukh, Michael

Sorry I couldn't make the call..too many meetings. :-(

>..

Our draft (draft-retana-network-complexity-framework) shows tradeoffs
(which may result in potential metrics) related to network design.

I agree that the framework should describe different types of
complexity..network design complexity being one of them.  My only concern
with including all forms of complexity, their description, metrics,
tradeoffs, etc. in one document is simply scope creep: we'll try to cover
too much and never finish.  The topic is already complex enough (pun
intended)!

IMHO, I would prefer the main framework document to briefly describe the
different forms (operational, design, etc.)..but then to have standalone
documents that supplement it by going deeper into a specific form and
describing the tradeoffs and maybe potential metrics.

My 2c.

Alvaro.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 14 May 2013 17:01:54 +0000

> Sorry I couldn't make the call..too many meetings. :-(

Same here...

>> this was presented in Paris.

If the framework includes all the forms, then including all tradeoffs and metrics of all forms in a single document will be a bit challenging, I suspect. The multitude of details will also deter from a simple framework.

>> 	+ Management system complexity

It seems there might be some overlaps and gaps on these various forms. 

> describing the tradeoffs and maybe potential metrics.

I agree with this proposal. I believe that the framework should provide the taxonomy, relationships, and definitions. But not the details and metrics. Companion documents could cover that.

Thanks,

-- Carlos.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 14 May 2013 17:02:37 +0000

> complexity..network design complexity being one of them.  My only
> concern with including all forms of complexity, their description, metrics,
> tradeoffs, etc. in one document is simply scope creep: we'll try to cover too
> much and never finish.  The topic is already complex enough (pun
> intended)!
> 

I think we agree. Obviously the framework will not be able to be exhaustive; I would like to define categories, and a list of examples in each category, with a brief discussion. Deeper analysis of a single metric, or exhaustive trade-off discussions should be in separate documents. 

I guess the question is where we draw the line. Open for discussion. Your cases are right on the border: As they are, they could be going into either, as I see it -  a bit more compact in the framework, or a bit more extensive in a separate doc. 

Do you agree? 

On the "categorisation" we need to think whether this is reasonably possible. Today I was looking at all the metrics mentioned in both documents; they range from very high-level ones like "cost" or "scalability" to much more specific ones like "control plane state". We could probably come up with even more deep metric, such as "peer state for IPsec tunnels" or whatever. Where do we draw the line? Does it make sense to list very high level metric alongside really detailed ones? Not clear to me right now... Ideas? 

Michael

---

From: David Meyer <[email-masked]>
Date: Wed, 15 May 2013 10:00:19 +0100

All,

Please see my comments on the framework draft (attached; search for
dmm> in-line). As you will see my reading of the framework is that it
is oriented towards algorithmic complexity, which is ok, but the
interesting complexity issues are really about structure. In that
sense I think the group is looking at a less interesting problem
(algorithmic complexity).

See in-line below for further comments. Thanks, --dmm

>> much and never finish.  The topic is already complex enough (pun

I don't see any crisp definition of complexity (network, design
otherwise) here. Again, it looks to be algorithmic complexity (which
again is interesting but not really what I think the focus of this
group should be about). BTW, for a good classification of problem
types (and hence complexity) see W. Weaver, “Science and complexity,”
American Scientist, vol. 6, pp.536–544, 1948. The key ideas are
summarized in
http://www.1-4-5.net/~dmm/talks/an_and_antifragility.pdf.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 15 May 2013 09:47:06 +0000

Hi, Michael and all,

My main concern for the current framework draft is how WG wants it end.

If the WG only wants to use the framework to be a working document, which records the WG's process, the current form seems fine. If the WG wants the document to be published as a RFC at the end, I think the current form has to be restructured. The current document looks more like a list of essay.

We need to find a way to organize these scattered idea into a single story. My suggestion is we should first try to reach consensus on a clear problem scope, or in other word, the purpose why we research network complexity. Then we can work out a story clue.

Best regards,

Sheng

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Michael Behringer (mbehring)
>Sent: Tuesday, May 14, 2013 11:30 PM
>To: [email-masked]
>Subject: [ncrg] Meeting Notes from Today's NCRG Call
>
>-	Rana: Should we limit to layer 3 and above? Or cover optical, wireless,
>etc? We may want to explain in the scope that the doc doesn't want to be
>specific to a particular solution/layer.
>-	Vladimir: participated in a Santa Fe Complex Systems Institute workshop
>on network complexity; will point us to it. Also a recent Nature article. He
>could present to the group about these findings in Berlin.
>
>Next steps:

---

From: Xin Sun <[email-masked]>
Date: Wed, 15 May 2013 20:16:30 -0400

> I guess the question is where we draw the line. Open for discussion. Your cases are right on the border: As they are, they could be going into either, as I see it -  a bit more compact in the frame…

I like the idea of first defining complexity "categories" -- this way we 
are more likely to have a common ground when discussing complexity. 
Right now it seems that different people may have different definitions 
and use different terms, which could be confusing in discussions. I 
think the best place to do this is in Section 3.2.

(If we are not able to "define" the categories at this stage, at least 
we can have some short descriptions of the characteristics of each. )

I also suggest to separate "complexity" with its "trade-offs". For 
example, in my opinion cost itself is not a form of complexity, but 
could be a trade-off with complexity. The same applies to reliability, 
perhaps. It would be good if we can make the distinction more clear.   
What we can probably do is that, after we defined the various complexity 
categories, we can separately define the various trade-offs with 
complexity.

> On the "categorisation" we need to think whether this is reasonably possible. Today I was looking at all the metrics mentioned in both documents; they range from very high-level ones like "cost" or…

I think the ideal metrics should be at the right level of abstraction, 
not too vague nor detailed.  Right level of abstraction means the  
metrics can apply to a large number of scenarios and mechanisms, yet 
remain quantitative.  ( e.g., "peer state for IPsec tunnels" seems a 
little too detailed to me as it only applies to the single scenario of 
setting up IP tunnels. "scalability" on the other hand is too vague 
since it is only qualitative. ).

-Xin

---

From: Luca Caviglione <[email-masked]>
Date: Thu, 16 May 2013 15:22:02 +0200

Hi Jiang, Michael and all,

I do agree with your vision. 

The "network of complexity" varies according to the viewpoint (e.g., service developer - planner - traffic engineer - physical).

As other suggested, it could be helpful to have a reference document with a quite abstract level of detail 
(in other words, I would draw the line very "far" from specific technicalities) and then some specialized documents. 
Yet, I would avoid to produce too many split information (years ago we did - IMHO - such a mistake in the P2PRG and
we lost completely focus and control of the needed work). 

My 2c too.

Best Regards,
Luca

PS: sorry for missing the meeting too.