[bmwg] AD review of draft-ietf-bmwg-dcbench-terminology.

Warren Kumari <warren@kumari.net> Tue, 23 May 2017 18:54 UTC

Return-Path: <warren@kumari.net>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214AE1293F5 for <bmwg@ietfa.amsl.com>; Tue, 23 May 2017 11:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 W2vYjeeXo3oO for <bmwg@ietfa.amsl.com>; Tue, 23 May 2017 11:54:18 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810E41270AC for <bmwg@ietf.org>; Tue, 23 May 2017 11:54:18 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id h16so63377124vkd.2 for <bmwg@ietf.org>; Tue, 23 May 2017 11:54:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=vn/Ly1eYU3AclgUrdHn0RAigbO5yViZax+8NdCb9wYs=; b=lhriQJszFZxXibGrvAdQDjOjhXUbZaSgf1/y+83XkiNUota4s3RWKB5PGS7z5qFy45 8C4B7iIE8X6NcmRzQ9u9yg0AQxVeF4d6tdgEcm6gsHiQLailmeCB42GmUVpDdlBrFRn5 q0sDwdGuIsfTMnUEzJuHEzUujQwQUSjwXT3unddBPI7H3NRYSwFyL2Oq8oAbkN5XZkAp 4/82Fk/iVodjU2y6G/PizjUone3OcN5vs72XQBmk30HnyzPld+PjuaD5NUxUKgfJxVQ2 L9fhuSVv1/f1RLzFr+EkvfB9ofSdJAo3xEux+QrGlnzG0uLye6SFdqab8v2ywub2MmU1 8YEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=vn/Ly1eYU3AclgUrdHn0RAigbO5yViZax+8NdCb9wYs=; b=D8sbspBQ/Spdb9jITjBWs20pyMiDO/4GW7MDOFAFAKFQBLIfa7nkVA+/+Qrtbb5St7 pJ0g3kV8MOmX+L3aX8Mf87TA1hZNa8y250t4jt+5lfXyWf+2OqVRWh/HsVK/6VSCYCyL mhlMfzxf8bxqwHouFgehSm00bjmGbSC3lwwbuRPCaJFq4jLDbVOxsxyKTBNTyNA5EZ29 ByxwtH0bUTa8RuqR+OHsuDn0lPqUPAFrrf9CwKByH/gaVx3MQ6b2ne3UhiIRYW/qyhqG +QifVJOgJ+Oy+Glewn299rPiSWcORNcnWpgPZetb/4dUDDzQK0oBqq4wzQOfriEO21cG 5sSA==
X-Gm-Message-State: AODbwcCxkVcFQsadxE4Rn3tEQFF7YQOfZUZp2YK/MmXk60m5zH/0VZgL jb2rU3y+pzuFPc1fOC6xSANoRNixW3Li
X-Received: by 10.31.173.142 with SMTP id w136mr11709168vke.125.1495565657113; Tue, 23 May 2017 11:54:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.71.83 with HTTP; Tue, 23 May 2017 11:53:36 -0700 (PDT)
From: Warren Kumari <warren@kumari.net>
Date: Tue, 23 May 2017 14:53:36 -0400
Message-ID: <CAHw9_i+yE8a02bP=NQym6nxUhCJM6OOdhkRwv=2GamQjV+KS1A@mail.gmail.com>
To: draft-ietf-bmwg-dcbench-terminology@ietf.org
Cc: bmwg@ietf.org
Content-Type: multipart/alternative; boundary="001a1143881ebb19ff0550358302"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/ZaZpEFvGve-WbYUM6LRNjFkDnUg>
X-Mailman-Approved-At: Tue, 23 May 2017 11:55:53 -0700
Subject: [bmwg] AD review of draft-ietf-bmwg-dcbench-terminology.
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 23 May 2017 18:54:22 -0000

Hi there,

Apologies, I had forgotten to click the AD eval button... {DONE}

Thanks for a (generally) clear and useful document.

I have completed my AD review of draft-ietf-bmwg-dcbench-terminology and 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.

W
------

Abstract

The purpose of this informational document is to establish definitions,
discussion and measurement techniques for data center benchmarking.
[O] establish definitions, discussion and measurement techniques
[R] I'm not sure what is meant by "discussion" here. "Discussion and
measurement techniques" doesn't make much sense to me. Perhaps "to
establish definitions, foster discussion and describe measurement
techniques ..."?



Also, it is to introduce new terminologies applicable to data center
[O] benchmarking. Also, it is to introduce
[P] benchmarking, as well as introduce
[R] clarity/no need for a separate sentence.

performance evaluations. The purpose of this document is not to define
the test methodology, but rather establish the important concepts when
one is interested in benchmarking network switches and routers in the
[O] when one is interested in benchmarking
[P] for benchmarking
[R] readability

data center.



1.  Introduction

   Traffic patterns in the data center are not uniform and are contently
[O] contently
[P] constantly
[R] word choice/typo

   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 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 can
   coexist in a single cluster and flow through a single network device
   all at the same time. Benchmarking of network devices have long used
[O] All of which can
   coexist in a single cluster and flow through a single network device
   all at the same time.
[P] One or more of these may coexist in a single cluster and flow through a
single network device simultaneously.
[R] grammar/readability - unless this changes the intent?

   [RFC1242], [RFC2432], [RFC2544], [2] and [3]. These benchmarks have
   largely been focused around various latency attributes and max
   throughput of the Device Under Test being benchmarked. These
   standards are good at measuring theoretical max throughput,
   forwarding rates and latency under testing conditions, but to not
[O] , but to not
[P]; but they do not
[R] grammar

   represent real traffic patterns that may affect these networking
   devices. The data center networking devices covered are switches and
   routers.



1.2. Definition format

   Term to be defined. (e.g., Latency)

   Definition: The specific definition for the term.

   Discussion: A brief discussion about the term, it's application and
[O] it's
[P] its
[R] Grammar. Should be a possessive, not a contraction of "it is."
   any restrictions on measurement procedures.

   Measurement Units: Methodology for the measure and units used to
   report measurements of this term, if applicable.


2.  Latency


2.1. Definition

   Latency is a the amount of time it takes a frame to transit the DUT.
   Latency is measured in unit of time (seconds, milliseconds,
   microseconds and so on). The purpose of measuring latency is to
   understand what is the impact of adding a device in the communication
[O]  understand what is the impact
[P] understand the impact
[R] grammar

   path.

   The Latency interval can be assessed between different combinations
   of events, irrespectively of the type of switching device (bit
[O] irrespectively
[P] regardless
[R] grammar

   forwarding aka cut-through or store forward type of device)



2.2 Discussion

   FILO is the most important measuring definition. Any type of switches
[O] Any type of switches
[P] All switches
[R] readability

   MUST be measured with the FILO mechanism: FILO will include the
   latency of the switch and the latency of the frame as well as the
   serialization delay. It is a picture of the 'whole' latency going
   through the DUT. For applications, which are latency sensitive and
   can function with initial bytes of the frame, FIFO MAY be an
   additional type of measuring to supplement FILO.


3 Jitter
3.2 Discussion

   In addition to PDV Range and or a high percentile of PDV, Inter-
[O]  and or
[P] and/or

   Packet Delay Variation (IPDV) as defined in section 4.1 of RFC5481
   (differences between two consecutive packets) MAY be used for the
   purpose of determining how packet spacing has changed during
   transfer, for example to see if packet stream has become closely-
[O] for example to see
[P] for example, to see
[R] grammar

   spaced or "bursty". However, the Absolute Value of IPDV SHOULD NOT be
   used, as this collapses the "bursty" and "dispersed" sides of the
   IPDV distribution together.

4 Physical Layer Calibration
4.2 Discussion

   Physical layer calibration is part of the end to end latency, which
   should be taken into acknowledgment while evaluating the DUT. Small
   variations of the physical components of the test may impact the
   latency being measure so they MUST be described when presenting
[O] latency being measure so
[P] latency being measured, so
[R] grammar

   results.


5 Line rate

5.1 Definition

   The transmit timing, or maximum transmitted data rate is controlled
   by the "transmit clock" in the DUT.  The receive timing (maximum
   ingress data rate) is derived from the transmit clock of the
   connected interface.

   The line rate or physical layer frame rate is the maximum capacity to
   send frames of a specific size at the transmit clock frequency of the
   DUT.

   The term port capacity term defines the maximum speed capability for
[O] The term port capacity term
[P] The term "port capacity"
[R] readability

   the given port; for example 1GE, 10GE, 40GE, 100GE etc.

   The frequency ("clock rate") of the transmit clock in any two
   connected interfaces will never be precisely the same, therefore a
   tolerance is needed, this will be expressed by Parts Per Million
[O] same, therefore a tolerance is needed, this will
[P] same; therefore, a tolerance is needed. This will
[R] grammar


5.2 Discussion

   For a transmit clock source, most Ethernet switches use "clock
   modules" (also called "oscillator modules") that are sealed,
   internally temperature-compensated, and very accurate. The output
   frequency of these modules is not adjustable because it is not
   necessary.  Many test sets, however, offer a software-controlled
   adjustment of the transmit clock rate, which should be used to
   compensate the test equipment to not send more than line rate of the
   DUT.

[O] which should be used to
   compensate the test equipment to not send more than line rate of the
   DUT.
[R] please reword for clarity.

   To allow for the minor variations typically found in the clock rate
   of commercially-available clock modules and other crystal-based


   Test set equipment manufacturers are well-aware of the standards, and
   allows a software-controlled +/- 100 PPM "offset" (clock-rate
[O] allows
[P] allow
[R] grammar

   adjustment) to compensate for normal variations in the clock speed of
   "devices under test". This offset adjustment allows engineers to
   determine the approximate speed the connected device is operating,
   and verify that it is within parameters allowed by standards.



5.3 Measurement Units


   In a production network, it is very unlikely to see precise line rate
   over a very brief period. There is no observable difference between
   dropping packets at 99% of line rate and 100% of line rate. -Line
   rate CAN measured at 100% of line rate with a -100PPM adjustment. -
   Line rate SHOULD be measured at 99,98% with 0 PPM adjustment.-The PPM
[O] .-The
[P] . The
[R] Typo Or was this intended to be a list?

   adjustment SHOULD only be used for a line rate type of measurement


6  Buffering
6.1 Buffer
6.1.1 Definition

   Buffer Size: the term buffer size, represents the total amount of
[O] the term buffer size, represents
[P] the term buffer size represents
[R] grammar

   frame buffering memory available on a DUT. This size is expressed in
   Byte; KB (kilobytes), MB (megabytes) or GB (gigabyte). When the
   buffer size is expressed it SHOULD be defined by a size metric
   defined above. When the buffer size is expressed, an indication of
[O]  defined above
[P] listed above [OR] stated above
[R] the sizes are not "defined" above

   the frame MTU used for that measurement is also necessary as well as
   the cos or dscp value set; as often times the buffers are carved by
   quality of service implementation. (please refer to the buffer
[O] . (please
[P] . (Please
[R] grammar

   efficiency section for further details).

   Example: Buffer Size of DUT when sending 1518 bytes frames is 18 Mb.

   Port Buffer Size: the port buffer size is the amount of buffer a
   single ingress port, egress port or combination of ingress and egress
   buffering location for a single port. The reason of mentioning the
[O] reason of mentioning
[P] reason for mentioning
[R] grammar

   three locations for the port buffer is, that the DUT buffering scheme
[O] is, that
[P] is because
[R] grammar


   can be unknown or untested, and therefore the indication of where the
   buffer is located helps understand the buffer architecture and
[O]  and therefore the indication of where the
   buffer is located helps understand the buffer architecture
[P] and so knowing the buffer location helps clarify the buffer architecture
[R] readability

   therefore the total buffer size. The Port Buffer Size is an
   informational value that MAY be provided from the DUT vendor. It is
   not a value that is tested by benchmarking. Benchmarking will be done
   using the Maximum Port Buffer Size or Maximum Buffer Size
   methodology.

   Maximum Port Buffer Size: this is in most cases the same as the Port
[O] this is in most cases the same
[P] in most cases, this is the same
[R] readability

   Buffer Size. In certain switch architecture called SoC (switch on
   chip), there is a concept of port buffer and shared buffer pool
[O] there is a concept
[R] ? in certain switch architecture there is a concept? Or is there an
actual port buffer?

   available for all ports. Maximum Port Buffer, defines the scenario of
   a SoC buffer, where this amount in B (byte), KB (kilobyte), MB
   (megabyte) or GB (gigabyte) would represent the sum of the port
   buffer along with the maximum value of shared buffer this given port
   can take. The Maximum Port Buffer Size needs to be expressed along
[O] Maximum Port Buffer, defines the scenario of
   a SoC buffer, where this amount in B (byte), KB (kilobyte), MB
   (megabyte) or GB (gigabyte) would represent the sum of the port
   buffer along with the maximum value of shared buffer this given port
   can take.
[P] Maximum Port Buffer, in terms of an SoC buffer, represents the sum of
the port buffer and the maximum value of shared buffer allowed for this
port, defined in terms of B (byte), KB (kilobyte), MB (megabyte), or GB
(gigabyte).
[R] readability - I think. I has a hard time parsing the previous sentence.

   with the frame MTU used for the measurement and the cos or dscp bit
   value set for the test.

   Example: a DUT has been measured to have 3KB of port buffer for 1518
   frame size packets and a total of 4.7 MB of maximum port buffer for
   1518 frame size packets and a cos of 0.

   Maximum DUT Buffer Size: this is the total size of Buffer a DUT can
   be measured to have. It is most likely different than the Maximum

[O] It is most likely different than
[P] either: It is, most likely, different to [OR] It is probably different
to
[R] grammar/readability

   Port Buffer Size. It CAN also be different from the sum of Maximum
   Port Buffer Size. The Maximum Buffer Size needs to be expressed along
   with the frame MTU used for the measurement and along with the cos or
   dscp value set during the test.

   Example: a DUT has been measured to have 3KB of port buffer for 1518
   frame size packets and a total of 4.7 MB of maximum port buffer for
   1518 frame size packets. The DUT has a Maximum Buffer Size of 18 MB
   at 1500 bytes and a cos of 0.

   Burst: The burst is a fixed number of packets sent over a percentage
   of linerate of a defined port speed. The amount of frames sent are
   evenly distributed across the interval T. A constant C, can be
[O] interval T. A constant C,
[P] interval, T. A constant, C,
[R] clarity

   defined to provide the average time between two consecutive packets
   evenly spaced.


6.1.2 Discussion

   When measuring buffering on a DUT, it is important to understand what
   the behavior is for each port, and also for all ports as this will
   provide an evidence of the total amount of buffering available on the
   switch. The terms of buffer efficiency here helps one understand what
[O] When measuring buffering on a DUT, it is important to understand what
   the behavior is for each port, and also for all ports as this will
   provide an evidence of the total amount of buffering available on the
   switch.
[P] When measuring buffering on a DUT, it is important to understand the
behavior for each and all ports. This provides data for the total amount of
buffering available on the switch.

   is the optimum packet size for the buffer to be used, or what is the
   real volume of buffer available for a specific packet size. This
[O] what is the optimum packet size for the buffer to be used, or what is
the
   real volume of buffer available for a specific packet size.
[P] the optimum packet size for the buffer, or the real volume of the
buffer available for a specific packet size
[R] readability

   section does not discuss how to conduct the test methodology, it
   rather explains the buffer definitions and what metrics should be
[O] , it rather explains
[P] ; instead, it explains
   provided for a comprehensive data center device buffering
   benchmarking.

6.1.3 Measurement Units

   When Buffer is measured:-the buffer size MUST be measured-the port
   buffer size MAY be provided for each port-the maximum port buffer
   size MUST be measured-the maximum DUT buffer size MUST be measured-
   the intensity of microburst MAY be mentioned when a microburst test
   is performed-the cos or dscp value set during the test SHOULD be
   provided

[O] entire paragraph above
[R] this is very difficult to read with the hyphens. Guessing this was
intended to be a list, but the XML got munged?

6.2 Incast
6.2.1 Definition

   The term Incast, very commonly utilized in the data center, refers to
   the traffic pattern of many-to-one or many-to-many conversations.
   Typically in the data center it would refer to many different ingress
   server ports(many), sending traffic to a common uplink (one), or
[O] ports(many)
[P] ports (many)

   multiple uplinks (many). This pattern is generalized for any network
   as many incoming ports sending traffic to one or few uplinks. It can
   also be found in many-to-many traffic patterns.


6.2.2 Discussion


   In this scenario, buffers are solicited on the DUT. In a ingress
   buffering mechanism, the ingress port buffers would be solicited
   along with Virtual Output Queues, when available; whereas in an
   egress buffer mechanism, the egress buffer of the one outgoing port
   would be used.

   In either cases, regardless of where the buffer memory is located on
   the switch architecture; the Incast creates buffer utilization.
[O] In either cases, regardless of where the buffer memory is located on
   the switch architecture; the Incast creates buffer utilization.
[P] In either case, regardless of where the buffer memory is located in the
switch architecture, the Incast creates the buffer utilization.
[R] grammar


   When one or more frames having synchronous arrival times at the DUT
   they are considered forming an incast.
[O] incast
[P] Incast
[R] consistency


7 Application Throughput: Data Center Goodput

7.3. Measurement Units

   Example: a TCP file transfer over HTTP protocol on a 10Gb/s media.
   The file cannot be transferred over Ethernet as a single continuous
   stream. It must be broken down into individual frames of 1500 bytes
   when the standard MTU [Maximum Transmission Unit] is used. Each
   packet requires 20 bytes of IP header information and 20 bytes of TCP
   header information, therefore 1460 byte are available per packet for
[O] information, therefore
[P] information; therefore,
[R] grammar

   the file transfer. Linux based systems are further limited to 1448
   bytes as they also carry a 12 byte timestamp. Finally, the date is
   transmitted in this example over Ethernet which adds a 26 byte
   overhead per packet.



-- 
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