[bmwg] AD review of draft-ietf-bmwg-dcbench-methodology

[Warren Kumari <[e-mail]>]

Hi there,

Thanks for another clear document - this makes a nice companion to
draft-ietf-bmwg-dcbench-terminology, and I'd like to progress them
together....

I have a number of suggested edits to make the document even more
readable / clearer. In a few instances I wasn't quite sure what the
document was trying to say, so please let me know if any of the
suggestions don't make sense, or change the text meaning...

Also, please poke me once updated, so that I can progress it to IETF LC...

------

1.  Introduction

   Traffic patterns in the data center are not uniform and are
   constantly changing. They are dictated by the nature and variety of
   applications utilized in the data center. It can be largely east-west
   traffic flows in one data center and north-south in another, while
   some may combine both. Traffic patterns can be bursty in nature and

[O] some
[P] others
[R] clarity

   contain many-to-one, many-to-many, or one-to-many flows. Each flow
   may also be small and latency sensitive or large and throughput
   sensitive while containing a mix of UDP and TCP traffic. All of which

[O] which
[P] these
[R] grammar

   can coexist in a single cluster and flow through a single network
   device all at the same time. Benchmarking of network devices have

[O] all at the same time
[P] simultaneously
[R] clarity

   long used [RFC1242], [RFC2432], [RFC2544], [2] and [3] which have
   largely been focused around various latency attributes and Throughput
   [2] of the Device Under Test (DUT) being benchmarked. These standards
   are good at measuring theoretical Throughput, forwarding rates and
   latency under testing conditions however, they do not represent real

[O] conditions however,
[P] conditions; however,
[R] grammar

   traffic patterns that may affect these networking devices.

....

1.2. Methodology format and repeatability recommendation


   For each test methodology described, it is critical to obtain
   repeatability in the results. The recommendation is to perform enough
   iterations of the given test and to make sure the result is
   consistent, this is especially important for section 3, as the

[O]  consistent, this
[P] consistent. This
[R] grammar

   buffering testing has been historically the least reliable. The
   number of iterations SHOULD be explicitly reported. The relative
   standard deviation SHOULD be below 10%.


2. Line Rate Testing

2.1 Objective

   Provide a maximum rate test for the performance values for
   Throughput, latency and jitter. It is meant to provide the tests to
   perform and methodology to verify that a DUT is capable of forwarding

[O] perform and methodology to verify
[P] perform, and methodology to verify,
[R] grammar

   packets at line rate under non-congested conditions.

2.3 Reporting Format

   -reading for Throughput received in percentage of bandwidth, while

[C]: Perhaps something like: - reading for "Throughput  received in
percentage of bandwidth", while...
(to make it clear where the "term" is)>

   sending 99.98% of port capacity on each port, for each packet size
   from 64 bytes to 9216 bytes. As guidance, an increment of 64 byte
   packet size between each iteration being ideal, a 256 byte and 512
   bytes being also often time used, the most common packets sizes order

[O] being also often time used, the
[P] are also often used. The
[R] grammar

   for the report is: 64b,128b,256b,512b,1024b,1518b,4096,8000,9216b.


6. Incast Stateful and Stateless Traffic
6.2 Methodology

   In order to simulate the effects of stateless and stateful traffic on
   the DUT there MUST be multiple ingress ports receiving traffic

[O] the DUT there
[P] the DUT, there
[R] grammar

   destined for the same egress port. There also MAY be a mix of
   stateful and stateless traffic arriving on a single ingress port. The
   simplest setup would be 2 ingress ports receiving traffic destined to
   the same egress port.

   One ingress port MUST be maintaining a TCP connection trough the

[O] trough
[P] through
[R] typo

   ingress port to a receiver connected to an egress port. Traffic in
   the TCP stream MUST be sent at the maximum rate allowed by the
   traffic generator. At the same time the TCP traffic is flowing

[O] At the same time the
[P] At the same time, the
[R] grammar

   through the DUT the stateless traffic is sent destined to a receiver
   on the same egress port. The stateless traffic MUST be a microburst
   of 100% intensity.


   Stateless Traffic port variation:

   During Iterations number of Egress ports MAY vary as well. First

[O] During Iterations number
[P] During Iterations, the number
[R] grammar

   Iteration: 1 Ingress port receiving stateful TCP traffic and 1
   Ingress port receiving stateless traffic destined to 1 Egress Port
----

Thanks.
Please poke me when integrated and I'll start the IETF LC on both.

W


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf