Subject: [bmwg] New work item proposal: Benchmarks for DCB switches

From: David Newman <[email-masked]>
Date: Fri, 14 Aug 2009 17:02:49 -0700

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