Re: [icnrg] [irsg] IRSG review for draft-irtf-icnrg-evaluation-methodology

Dirk Kutscher <Dirk.Kutscher@neclab.eu> Mon, 04 January 2016 19:18 UTC

Return-Path: <Dirk.Kutscher@neclab.eu>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735AB1A8A4C; Mon, 4 Jan 2016 11:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37YZuY3LEOiZ; Mon, 4 Jan 2016 11:18:45 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BD21A909C; Mon, 4 Jan 2016 11:18:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 804A610BA9B; Mon, 4 Jan 2016 20:18:38 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un59ePWonmM8; Mon, 4 Jan 2016 20:18:38 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 4D53F10BA9A; Mon, 4 Jan 2016 20:18:32 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.84]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Mon, 4 Jan 2016 20:18:11 +0100
From: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
To: Aaron Falk <aaron.falk@gmail.com>
Thread-Topic: [irsg] IRSG review for draft-irtf-icnrg-evaluation-methodology
Thread-Index: AdEngE3SZkDP8ciAThaACIOein5wxAbCuRYAASZGyeA=
Date: Mon, 04 Jan 2016 19:18:10 +0000
Message-ID: <82AB329A76E2484D934BBCA77E9F5249A9ED24A5@PALLENE.office.hd>
References: <82AB329A76E2484D934BBCA77E9F5249A67AE47A@PALLENE.office.hd> <CAD62q9Uv-2wfCiRX6yLRAzY=dBgDYUFcY2zn4eH6HHb8D9paQg@mail.gmail.com>
In-Reply-To: <CAD62q9Uv-2wfCiRX6yLRAzY=dBgDYUFcY2zn4eH6HHb8D9paQg@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.197]
Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F5249A9ED24A5PALLENEofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/icnrg/l6a5l6b54Yw4o3hwy-2KDPsa_AI>
Cc: "icnrg@irtf.org" <icnrg@irtf.org>, "Internet Research Steering Group (irsg@irtf.org)" <irsg@irtf.org>
Subject: Re: [icnrg] [irsg] IRSG review for draft-irtf-icnrg-evaluation-methodology
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2016 19:18:48 -0000

Hi Aaron,

thanks a lot for the review! These are helpful comments.

Authors, can you discuss how you want to address this and let us know?

In case there is a need for discussion or further clarification, let’s do that on icnrg@irtf.org<mailto:icnrg@irtf.org>.

Cheers,
Dirk



From: Aaron Falk [mailto:aaron.falk@gmail.com]
Sent: Mittwoch, 30. Dezember 2015 00:50
To: Dirk Kutscher
Cc: Internet Research Steering Group (irsg@irtf.org); icnrg@irtf.org
Subject: Re: [irsg] IRSG review for draft-irtf-icnrg-evaluation-methodology

Hi Dirk-

Here's my review.  It's an interesting doc.  I'm happy to correspond about any of my comments.

--aaron

High level comments:

  *   I'm not quite sure this document provides a methodology.  A better title might be "Evaluation Considerations"
  *   Section 2 isn't required by Section 3 and is a little off the focus of the document.  I recommend moving Section 2 to after Section 4, possibly to an appendix.

Other comments:

Section 1:

   This document incorporates input from ICNRG participants and their

   corresponding text contributions; it has been reviewed by several

   ICNRG active participants (see section 7<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#section-7>), and represents the

   consensus of the research group.

[AF] This is  first mention of the ICNRG and comes without expansion or definition.  Since you say earlier that the audience is the "ICN ... researchers and practitioners" I wouldn't expect them to know about the RG (indeed, RFCs live longer than RGs and the ICNRG may be a distant memory).  Thus, I suggest adding a short paragraph describing the RG's goals and members.

Section 2.2:
[AF] The section starts with a nice summary of requirements but the descriptions of the various tools should include some discussion of how well the requirements are met.


   The Icarus simulator [ICARUS<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-ICARUS>] implements ProbCache [PROBCACH<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-PROBCACH>],

   centrality-based in-network caching [CL4M<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-CL4M>]

[AF] "centrality-based" must be a ICN phrase.  It isn't meaningful to me.  Is there a less jargon-y phrase that can be used?

Section 2.3:
[AF] Given the discussion of requirements for tools, why no requirements for facilities?  E.g., low cost of use, reproducible configuration, easy-to-use tools, sharable, available background traffic...


   Often, central to the assessment of the features provided by

   a novel mechanism, lies the consideration of how it improves over

   already existing technologies, and by "how much."

[AF] Strike "Often,"

Section 3:

   This section considers techniques and options available for several

   key aspects of any evaluation method.

[AF] Given the draft title is "Information-centric Networking: Evaluation Methodology", I assume this section is the meat of the document and yet there is only a trivial introduction.  Throw the reader a bone, eh?  What am I going to hear about?  Am I to select one of the approaches described?  Or are these considerations for any evaluation technique?  Is there a relationship between the tools and facilities of the prior sections and methodologies?

Section 3.1.  Topology Selection
[AF] There's been a lot of prior work on topologies for simulation & performance evaluation.  Does ICN change any of that?  This section is a little of a hodgepodge of information.  It's hard to take away much insight on how topology selection applies to ICN evaluation.  It would benefit from a re-write that is clearer on what questions the section is supposed to answer (and then answers them).

Section 3.2.  Traffic Load

Table III. Content catalog



   Traffic | Catalog |  Mean Object Size  |  Popularity Distribution

   Load    | Size    |  [L4<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L4>][L5][L7<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L7>][L8]  |  [L3<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L3>][L5][L6<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L6>][L11][L12<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L12>]

           | [L1<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L1>][L2]|  [L9<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L9>][L10]         |

           | [L3<https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-03#ref-L3>][L5]|                    |

   ==================================================================

   VoD     |  10^4   | Object: ~100 MB    | Zipf, 0.65 <= alpha <= 1

   ==================================================================

[AF] Video traffic has largely migrated to HTTP Adaptive Streaming where chunks are separate web objects and may be cached separately.  For example, the first 10 minutes of a movie may be more popular than the rest and cached in more places.  Treating VoD as a single 100MB object doesn't reflect this.

Section 3.3.  Choosing Relevant Metrics

   ICN is a networking concept that arose from the desire to align the

   operation model of a network with the model of its typical use.  For

   TCP/IP networks, this implies changing the mechanisms of data access

   and transport from a host-to-host model to a user-to-information

   model.  The premise is that the effort invested in changing models

   will be offset, or even surpassed, by the potential of a "better"

   network.  However, such a claim can be validated only if it is

   quantified.

[AF] This is a great introductory paragraph.  Suggest moving it to Section 1.


   ICN approaches have used system metrics, but unfortunately

   the situation is not as coherent as with the traffic metrics.

[AF] This statement isn't supported.  How is the use of system metrics not coherent?  What does this statement mean?



On Wed, Nov 25, 2015 at 8:07 AM, Dirk Kutscher <Dirk.Kutscher@neclab.eu<mailto:Dirk.Kutscher@neclab.eu>> wrote:
Hello IRSG,

ICNRG has reached consensus on moving forward with another document that now needs IRSG review:

https://datatracker.ietf.org/doc/draft-irtf-icnrg-evaluation-methodology/

This document surveys the evaluation tools currently available to
researchers in the information-centric networking (ICN) area and
provides suggestions regarding methodology and metrics.  Further,
this document sheds some light on the impact of ICN on network
security.

Looking at our review assignment table, next in line would be Aaron.

Aaron, do you have a chance to review this?

Thanks,
Dirk