Re: [bmwg] Re-Charter Text for review

joel jaeggli <joelja@bogus.com> Sun, 04 May 2014 12:27 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6A71A0081 for <bmwg@ietfa.amsl.com>; Sun, 4 May 2014 05:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 JYqtUKGJ1rYs for <bmwg@ietfa.amsl.com>; Sun, 4 May 2014 05:27:05 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8B74B1A007C for <bmwg@ietf.org>; Sun, 4 May 2014 05:27:05 -0700 (PDT)
Received: from mb-aye.local (75-148-161-129-Houston.hfc.comcastbusiness.net [75.148.161.129]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s44CQrEr047907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 May 2014 12:26:54 GMT (envelope-from joelja@bogus.com)
Message-ID: <53663208.6040600@bogus.com>
Date: Sun, 04 May 2014 07:26:48 -0500
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0
MIME-Version: 1.0
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>
References: <2845723087023D4CB5114223779FA9C8017944B077@njfpsrvexg8.research.att.com> <2845723087023D4CB5114223779FA9C801795CD426@njfpsrvexg8.research.att.com>
In-Reply-To: <2845723087023D4CB5114223779FA9C801795CD426@njfpsrvexg8.research.att.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="qQGVLhAerWtOeX7tOTJTT8cjfwljES5Wa"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 04 May 2014 12:26:54 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/xzS97NNF6Inw-lpc0YuvmSEGYOE
Cc: "bmwg@ietf.org" <bmwg@ietf.org>
Subject: Re: [bmwg] Re-Charter Text for review
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 12:27:07 -0000

Thank you,

I think we can work with that as a proposal for the IESG.

While it's not directly the basis for evaluation we should sketch out
the milestones that in the near term we are undertaking against the
charter items.

joel

On 5/3/14, 3:20 PM, MORTON, ALFRED C (AL) wrote:
> Description of Working Group:
> 
> 
> The Benchmarking Methodology Working Group (BMWG) will continue to
> produce a series of recommendations concerning the key performance
> characteristics of internetworking technologies, or benchmarks for
> network devices, systems, and services. Taking a view of networking
> divided into planes, the scope of work includes benchmarks for the
> management, control, and forwarding planes.
> 
> Each recommendation will describe the class of equipment, system, or
> service being addressed; discuss the performance characteristics that
> are pertinent to that class; clearly identify a set of metrics that aid
> in the description of those characteristics; specify the methodologies
> required to collect said metrics; and lastly, present the requirements
> for the common, unambiguous reporting of benchmarking results.
> 
> The set of relevant benchmarks will be developed with input from the
> community of users (e.g., network operators and testing organizations)
> and from those affected by the benchmarks when they are published
> (networking and test equipment manufacturers). When possible, the
> benchmarks and other terminologies will be developed jointly with
> organizations that are willing to share their expertise. Joint review
> requirements for a specific work area will be included in the detailed
> description of the task, as listed below.
> 
> To better distinguish the BMWG from other measurement initiatives in the
> IETF, the scope of the BMWG is limited to the characterization of
> implementations of various internetworking technologies
> using controlled stimuli in a laboratory environment. Said differently,
> the BMWG does not attempt to produce benchmarks for live, operational
> networks. Moreover, the benchmarks produced by this WG shall strive to
> be vendor independent or otherwise have universal applicability to a
> given technology class.
> 
> Because the demands of a particular technology may vary from deployment
> to deployment, a specific non-goal of the Working Group is to define
> acceptance criteria or performance requirements.
> 
> An ongoing task is to provide a forum for development and
> advancement of measurements which provide insight on the
> capabilities and operation of implementations of inter-networking technology.
> 
> The BMWG will communicate with the operations community through
> organizations such as NANOG, RIPE, and APRICOT.
> 
> In addition to its current work items, the BMWG is explicitly tasked to
> develop benchmarks and methodologies for the following technologies:
> 
> Traffic Management: Develop the methods to characterize the capacity 
> of traffic management features in network devices, such as classification, 
> policing, shaping, and active queue management. Existing terminology 
> will be used where appropriate. Configured operation will be verified 
> as a part of the methodology. The goal is a methodology to assess the 
> maximum forwarding performance that a network device can sustain without 
> dropping or impairing packets, or compromising the accuracy of multiple 
> instances of traffic management functions. This is the benchmark for 
> comparison between devices. Another goal is to devise methods that 
> utilize flows with congestion-aware transport as part of the traffic 
> load and still produce repeatable results in the isolated test environment.
> 
> IPv6 Neighbor Discovery: Large address space in IPv6 subnets presents 
> several networking challenges, as described in RFC 6583. Indexes to 
> describe the performance of network devices, such as the number of 
> reachable devices on a sub-network, are useful benchmarks to the 
> operations community. The BMWG will develop the necessary 
> terminology and methodologies to measure such benchmarks.
> 
> In-Service Software Upgrade: Develop new methods and benchmarks to 
> characterize the upgrade of network devices while in-service, 
> considering both data and control plane operations and impacts. 
> These devices are generally expected to maintain control plane session 
> integrity, including routing connections. Quantification of upgrade 
> impact will include packet loss measurement, and other forms of recovery 
> behavior will be noted accordingly. The work will produce a definition 
> of ISSU, which will help refine the scope. Liaisons will be established 
> as needed.
> 
> Data Center Benchmarking: This work will define additional terms, 
> benchmarks, and methods applicable to data center performance evaluations. 
> This includes data center specific congestion scenarios, switch buffer 
> analysis, microburst, head of line blocking, while also using a wide mix 
> of traffic conditions. Some aspects from BMWG's past work are not 
> meaningful when testing switches that implement new IEEE specifications 
> in the area of data center bridging. For example, throughput as defined 
> in RFC 1242 cannot be measured when testing devices that implement three 
> new IEEE specifications: priority-based flow control (802.1Qbb); 
> priority groups (802.1Qaz); and congestion notification (802.1Qau).
> This work will update RFC1242, RFC2544, RFC2889 (and other key RFCs), 
> and exchange Liaisons with relevant SDOs, especially at WG Last Call.
> 
> VNF and Related Infrastructure Benchmarking: Benchmarking Methodologies 
> have reliably characterized many physical devices. This work item extends 
> and enhances the methods to virtual network functions (VNF) and their 
> unique supporting infrastructure. First, the new task space will be 
> considered to ensure that common issues are recognized from the start. 
> Benchmarks for platform capacity and performance characteristics of 
> virtual routers, switches, and related components will follow, including 
> comparisons between physical and virtual network functions.
> 
>