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

Xin Sun <xinsun@cs.fiu.edu> Thu, 16 May 2013 00:16 UTC

Return-Path: <xinsun@cs.fiu.edu>
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 02A2911E80E0 for <ncrg@ietfa.amsl.com>; Wed, 15 May 2013 17:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-VrOYaK7Xok for <ncrg@ietfa.amsl.com>; Wed, 15 May 2013 17:16:40 -0700 (PDT)
Received: from cheetah.cs.fiu.edu (cheetah.cs.fiu.edu [131.94.130.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA8511E80D7 for <ncrg@irtf.org>; Wed, 15 May 2013 17:16:37 -0700 (PDT)
Received: from [131.94.129.226] (queen.cs.fiu.edu [131.94.129.226]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by cheetah.cs.fiu.edu (Postfix) with ESMTPSA id 42671DBE8 for <ncrg@irtf.org>; Wed, 15 May 2013 20:16:30 -0400 (EDT)
Message-ID: <5194255E.6070609@cs.fiu.edu>
Date: Wed, 15 May 2013 20:16:30 -0400
From: Xin Sun <xinsun@cs.fiu.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: ncrg@irtf.org
References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D50A0F1@xmb-rcd-x14.cisco.com> <BBD66FD99311804F80324E8139B3C94E11E1C271@xmb-aln-x15.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D50A3B0@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D50A3B0@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ncrg] Meeting Notes from Today's NCRG Call
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: Thu, 16 May 2013 00:16:45 -0000

On 5/14/2013 1:02 PM, Michael Behringer (mbehring) wrote:

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

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

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


>
> Michael
>   
>> My 2c.
>>
>> Alvaro.
> _______________________________________________
> ncrg mailing list
> ncrg@irtf.org
> https://www.irtf.org/mailman/listinfo/ncrg