[bmwg] New work item proposal: Benchmarks for DCB switches
David Newman <dnewman@networktest.com> Sat, 15 August 2009 00:02 UTC
Return-Path: <dnewman@networktest.com>
X-Original-To: bmwg@core3.amsl.com
Delivered-To: bmwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36163A6DBD for <bmwg@core3.amsl.com>; Fri, 14 Aug 2009 17:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBgcC5CdDoch for <bmwg@core3.amsl.com>; Fri, 14 Aug 2009 17:02:46 -0700 (PDT)
Received: from mail.networktest.com (mail.networktest.com [216.240.60.134]) by core3.amsl.com (Postfix) with ESMTP id 9C1FC3A68B9 for <bmwg@ietf.org>; Fri, 14 Aug 2009 17:02:46 -0700 (PDT)
Received: from levi.local (cpe-76-83-12-67.socal.res.rr.com [76.83.12.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.networktest.com (Postfix) with ESMTPSA id D2F8278C94 for <bmwg@ietf.org>; Fri, 14 Aug 2009 17:02:50 -0700 (PDT)
Message-ID: <4A85FB29.2030909@networktest.com>
Date: Fri, 14 Aug 2009 17:02:49 -0700
From: David Newman <dnewman@networktest.com>
Organization: Network Test Inc.
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: bmwg@ietf.org
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: [bmwg] New work item proposal: Benchmarks for DCB switches
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 15 Aug 2009 00:02:47 -0000
BMWGers, Timmons Player and I would like to propose extensions to 2544 and 2889 to test many switches now or soon coming to market with "data center bridging" features such as priority-based flow control. A full work item proposal follows. The short version is "RFC 1242 throughput is no longer meaningful if packet loss never occurs." To address this, we propose a new metric, queueput, and several tests specific to switches that use priority-based flow control. We expect these tests will be useful in assessing performance of switches intended to combine traffic from data and storage networks. We also have prepared a strawman ID as an individual submission: http://www.ietf.org/id/draft-player-dcb-benchmarking-00.txt We encourage the BMWG to take this up as a new work item, and welcome your comments and questions. dn NEW WORK ITEM PROPOSAL: BENCHMARKS FOR DATA CENTER BRIDGING DEVICES SUMMARY Existing benchmarking methodologies assume network devices will drop traffic at their performance limits. However, devices implementing Data Center Bridging (DCB) mechanisms such as IEEE 802.1Qbb priority flow control will throttle link partners before those limits are reached. Thus, existing methodologies based around frame loss are not appropriate for such devices. For example, it is not possible to determine RFC 1242 throughput for a DCB device that, correctly implemented, does not drop frames. Similarly, the overload conditions described in RFCs 2285 and 4689 cannot be achieved because frame loss should never occur in correctly implemented DCB devices. This work item proposes to extend existing bmwg work to support “lossless” Ethernet devices that implement priority flow control and related DCB mechanisms. The extensions include a new metric called “queueput” as well as extensions to existing metrics for performance measurement in a DCB context. GOAL This work item proposes to extend existing bmwg documents with new terminology and methodology specific to performance characterization of DCB devices. As vendors and end-users adopt DCB technology, especially to converge storage and data networks, this set of commonly understood performance benchmarks will be useful in reducing the amount of “specsmanship” lamented in RFC 1242. SCOPE This work item will focus on DCB-specific extensions to RFCs 1242, 2544, 2285, 2889 and 4689. The key DCB mechanism used in testing will be IEEE 802.1Qbb priority flow control. New terminology specific to DCB testing will be defined. Existing terms will be re-used where possible, making clear each term’s use in a DCB context. For example, in DCB testing the “Classification” criterion will be the 802.1p priority field of the 802.1Q VLAN header. Test methodology will cover at least four areas: Queueput (new metric) Maximum forwarding rate (existing, made specific to DCB devices) Back-off (existing, made specific to DCB devices) Back-to-back (existing, made specific to DCB devices) For each test, the methodology will define DCB-relevant configuration and reporting criteria as well as describing procedures. MOTIVATION A number of switch and router implementations already have or soon will come to market that implement “lossless” DCB mechanisms such as priority flow control. Existing bmwg documents are not appropriate for performance measurement of such DUTs because of the assumption that loss will follow congestion. While bmwg practices generally remain valuable in describing the limits of device performance, new extensions are needed specific to devices that implement DCB mechanisms. PROPOSED SCHEDULE August 2009: Initial ID draft 0 and proposed work item August-September 2009: Discussion on bmwg mailing list; decision to adopt (or otherwise) by bmwg; if adoption, charter revision to add to bmwg scope October 2009: Preparation of draft 1 incorporating comments from mailing list November 2009: Discussion at Hiroshima IETF (if bmwg meets there) December 2009: Preparation of draft 2 incorporating comments from mailing list Late winter/early spring 2010: Move to WGLC