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

David Meyer <> Wed, 15 May 2013 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18F3C21F852A for <>; Wed, 15 May 2013 02:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dJeGSnNHZXSF for <>; Wed, 15 May 2013 02:00:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22c]) by (Postfix) with ESMTP id DB34D21F8470 for <>; Wed, 15 May 2013 02:00:20 -0700 (PDT)
Received: by with SMTP id z1so268715qcx.31 for <>; Wed, 15 May 2013 02:00:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Lcr1LEmt5J1DGG9iLyG7D7p0WP8wQZWq7kQKk7ayuVM=; b=hruZrJ3KGQRpJkAV7j5QfJyOTA8ZwljRBR7RLFyqXGRSlITMpnSrxq0aot9AXnW7k0 9z4sG+RA830x+bTONo57rJiuW+A727QctOEQyN81LojFz1Ta9Sqq0aoWaLQWTg+hIjwb cImQipJPEukNiQr13KIn+goe4yNwcnOdtCNZqEg3gilYikgObxPV0SQVn1q2SsDCu/zg engL5k2HacdHiRKdCySfKkVEeqWnpgbqKdzWP6PsXmhgwsdCYl4o/Ein/42QHnyeNdjY iYYfc/ATdLdx3yzrRx17A9pS4BrJ0B/ID83E8Hpt4aLERpI8BvL28iRc/G2wMq4LarbV prOA==
MIME-Version: 1.0
X-Received: by with SMTP id dr8mr31345180qeb.43.1368608420015; Wed, 15 May 2013 02:00:20 -0700 (PDT)
Received: by with HTTP; Wed, 15 May 2013 02:00:19 -0700 (PDT)
X-Originating-IP: [2001:67c:64:42:a8e3:5a9c:14c2:4ba6]
In-Reply-To: <>
References: <> <> <>
Date: Wed, 15 May 2013 10:00:19 +0100
Message-ID: <>
From: David Meyer <>
To: "Michael Behringer (mbehring)" <>
Content-Type: multipart/mixed; boundary=047d7b6da860b641ef04dcbdfa1e
X-Gm-Message-State: ALoCoQkwvT0Gy8/cPcUkk7eUS6BqzPBL10D1LX5s8YOG/7BILKc8TqRwZ6hwgJk/H5w9UgR9nbvV
Cc: "Alvaro Retana \(aretana\)" <>, "" <>
Subject: Re: [ncrg] Meeting Notes from Today's NCRG Call
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, 15 May 2013 09:00:23 -0000


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)
<> 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
>> 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

>> 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