Re: [bmwg] New Charter Paragraphs

"Lucien Avramov (lavramov)" <lavramov@cisco.com> Wed, 23 April 2014 06:30 UTC

Return-Path: <lavramov@cisco.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 D2DC91A0330 for <bmwg@ietfa.amsl.com>; Tue, 22 Apr 2014 23:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.773
X-Spam-Level:
X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 JDIoEwVa0apb for <bmwg@ietfa.amsl.com>; Tue, 22 Apr 2014 23:30:53 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33E3D1A008F for <bmwg@ietf.org>; Tue, 22 Apr 2014 23:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6292; q=dns/txt; s=iport; t=1398234648; x=1399444248; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vCbTWP9XoyqzN0vPRm/8z/or0w8yAZ+Q4Qgc8RfYNRs=; b=ixGAPugQVA5bGBpcqkei6o/dYtuO8lt/DqIOZjQgFyNaj9Y50ULXZOSI bV2vAjY6RrmX0eMDkE22egB5HJuXGbO2g8z/P9JqBKVBE3rCjqvVLXuIv WUvyPCxzFWtA004LzA8AVmht4J8Rw7YmuN1aE3UyIKMFslLipLsJZRVaR k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFADRdV1OrRDoH/2dsb2JhbABZgwZPvVmHOoEWFnSCJQEBAQQBAQE1NgoRCxEEAQEBCRYPCQMCAQIBFSgIBgEMBgIBAQWINw7PLReOX4Q5AQOJZY8QgTeRHoNRHQ
X-IronPort-AV: E=Sophos;i="4.97,910,1389744000"; d="scan'208";a="110880423"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 23 Apr 2014 06:30:44 +0000
Received: from sjc-lavramov-8816.cisco.com (sjc-lavramov-8816.cisco.com [10.19.100.135]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3N6Ui0e018854; Wed, 23 Apr 2014 06:30:44 GMT
Message-ID: <53575E93.3000103@cisco.com>
Date: Tue, 22 Apr 2014 23:32:51 -0700
From: "Lucien Avramov (lavramov)" <lavramov@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>, "bmwg@ietf.org" <bmwg@ietf.org>
References: <2845723087023D4CB5114223779FA9C8017910D8A2@njfpsrvexg8.research.att.com>, <534B85FD.8050102@cisco.com> <2845723087023D4CB5114223779FA9C80178E0CD46@njfpsrvexg8.research.att.com>
In-Reply-To: <2845723087023D4CB5114223779FA9C80178E0CD46@njfpsrvexg8.research.att.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/Q-R74A0GMYAlW4uFmky4jhmSb7o
Subject: Re: [bmwg] New Charter Paragraphs
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: Wed, 23 Apr 2014 06:30:58 -0000

Hi Al,

This looks good to me, I think we should not restrict the charter to 
only update 2544, I would extend this to : RFC1242, RFC2432, RFC2544, 
RFC2889 and RFC3918 as per our drafts for the data center benchmarking 
mention in the abstract sections:

http://www.ietf.org/internet-drafts/draft-dcbench-def-01.txt
http://www.ietf.org/id/draft-bmwg-dcbench-methodology-02.txt

Cheers,
Lucien


On 4/18/14, 9:36 AM, MORTON, ALFRED C (AL) wrote:
> How about this combined version?
>
> 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 RFC 2544 and exchange periodic
> Liaisons with relevant SDOs, especially at WG Last Call.
>
>
> ________________________________________
> From: Lucien Avramov (lavramov) [lavramov@cisco.com]
> Sent: Monday, April 14, 2014 2:53 AM
> To: MORTON, ALFRED C (AL); bmwg@ietf.org
> Subject: Re: [bmwg] New Charter Paragraphs
>
> Hello BMWG!
>
> Suggesting some edits for the DC portion of the charter to include the
> benchmarking we have been talking and presenting at IEFT for the last
> year with Jacob Rapp:
>
> Data Center:
>
> -Bridging
> Some key concepts 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).
>       Since devices that implement these new congestion-management
>       specifications should never drop frames, and since the metric of
>       throughput distinguishes between non-zero and zero drop rates, no
>       throughput measurement is possible using the existing methodology.
>       The current emphasis is on the Priority Flow Control aspects of
>       Data Center Bridging, and the work will include an investigation
>       into whether TRILL RBridges require any specific treatment in the
>       methodology. This work will update RFC 2544 and exchange periodic
>       Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call.
>
> -Benchmarking Data Center DUT:
> The purpose of this informational document is to establish definitions,
> discussion and measurement techniques specific to data center
> environments. It is also to introduce definition terminologies
> applicable to data center performance evaluations. With these
> established, a methodology and measurement techniques for network
> equipement in the data center are covered. This includes data center
> specific congestion scenarios, switch buffer analysis, microburst,
> head of line blocking, while also using a wide mix of traffic
> conditions. This complements the existing benchmarking RFCs by
> specifying data center centric benchmarking.
>
> Cheers,
> Lucien
>
> On 3/27/14, 12:53 PM, MORTON, ALFRED C (AL) wrote:
>> BMWG,
>>
>> As we close in on the re-charter text, we decided at our IETF-89 session
>> to keep Datacenter and VNF paragraphs separate.
>>
>> To that end, we already have a Datacenter-oriented paragraph in our charter,
>> but it needs editing -- please make suggestions!
>>
>> * Data Center Bridging Devices:
>>       Some key concepts 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).
>>       Since devices that implement these new congestion-management
>>       specifications should never drop frames, and since the metric of
>>       throughput distinguishes between non-zero and zero drop rates, no
>>       throughput measurement is possible using the existing methodology.
>>       The current emphasis is on the Priority Flow Control aspects of
>>       Data Center Bridging, and the work will include an investigation
>>       into whether TRILL RBridges require any specific treatment in the
>>       methodology. This work will update RFC 2544 and exchange periodic
>>       Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call.
>>
>>
>> Also, here's the (slightly modified) text for VNF activity:
>>
>> * 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 considered  from the start.
>> Virtual routers, switches and platform capacity and performance characteristics
>> will follow, including comparisons between physical and virtual functions.
>>
>> Finally, I'll leave it to the authors to say more, but I noticed a new draft
>> on our tools page:
>>
>> http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-benchmarking-00
>>
>> take a look, is this something we should consider including on our ride?
>>
>> Comments by April 14th, please.
>>
>> regards,
>> Al/Sarah
>> bmwg co-chairs
>>
>> _______________________________________________
>> bmwg mailing list
>> bmwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/bmwg
>>