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

[David Meyer <[e-mail]>]

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

On Tue, May 14, 2013 at 6:02 PM, Michael Behringer (mbehring)
<[e-mail]> wrote:
>> 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)!

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.

>>
>> 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.
>
> 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
>
>> My 2c.
>>
>> Alvaro.
>
> _______________________________________________
> ncrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/ncrg