Internet Engineering Task Force (IETF) L. Avramov
Request for Comments: 8239 Google
Category: Informational J. Rapp
ISSN: 2070-1721 VMware
August 2017
Internet Engineering Task Force (IETF) L. Avramov
Request for Comments: 8239 Google
Category: Informational J. Rapp
ISSN: 2070-1721 VMware
August 2017
Data Center Benchmarking Methodology
数据中心基准测试方法
Abstract
摘要
The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.
本信息文件的目的是为数据中心的物理网络设备建立测试和评估方法以及测量技术。RFC 8238是本文件的先决条件，因为其中包含被视为规范性的术语。由于最初应用于数据中心的技术部署在其他地方，这些术语和方法中的许多可能超出了本文档的范围。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8239.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8239.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. Methodology Format and Repeatability Recommendation ........4
2. Line-Rate Testing ...............................................4
2.1. Objective ..................................................4
2.2. Methodology ................................................4
2.3. Reporting Format ...........................................5
3. Buffering Testing ...............................................6
3.1. Objective ..................................................6
3.2. Methodology ................................................7
3.3. Reporting Format ...........................................9
4. Microburst Testing .............................................10
4.1. Objective .................................................10
4.2. Methodology ...............................................10
4.3. Reporting Format ..........................................11
5. Head-of-Line Blocking ..........................................12
5.1. Objective .................................................12
5.2. Methodology ...............................................12
5.3. Reporting Format ..........................................14
6. Incast Stateful and Stateless Traffic ..........................15
6.1. Objective .................................................15
6.2. Methodology ...............................................15
6.3. Reporting Format ..........................................17
7. Security Considerations ........................................17
8. IANA Considerations ............................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
Acknowledgments ...................................................19
Authors' Addresses ................................................19
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. Methodology Format and Repeatability Recommendation ........4
2. Line-Rate Testing ...............................................4
2.1. Objective ..................................................4
2.2. Methodology ................................................4
2.3. Reporting Format ...........................................5
3. Buffering Testing ...............................................6
3.1. Objective ..................................................6
3.2. Methodology ................................................7
3.3. Reporting Format ...........................................9
4. Microburst Testing .............................................10
4.1. Objective .................................................10
4.2. Methodology ...............................................10
4.3. Reporting Format ..........................................11
5. Head-of-Line Blocking ..........................................12
5.1. Objective .................................................12
5.2. Methodology ...............................................12
5.3. Reporting Format ..........................................14
6. Incast Stateful and Stateless Traffic ..........................15
6.1. Objective .................................................15
6.2. Methodology ...............................................15
6.3. Reporting Format ..........................................17
7. Security Considerations ........................................17
8. IANA Considerations ............................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
Acknowledgments ...................................................19
Authors' Addresses ................................................19
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. They can be largely east-west traffic flows (server to server inside the data center) in one data center and north-south (from the outside of the data center to the server) in another, while others 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 these can coexist in a single cluster and flow through a single network device simultaneously. Benchmarking tests for network devices have long used [RFC1242], [RFC2432], [RFC2544], [RFC2889], and [RFC3918], which have largely been focused around various latency attributes and throughput [RFC2889] 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 traffic patterns that may affect these networking devices.
数据中心的流量模式并不统一，而且不断变化。它们由数据中心中使用的应用程序的性质和种类决定。它们可以是一个数据中心中的东西向交通流（数据中心内部的服务器到服务器），也可以是另一个数据中心中的南北向交通流（从数据中心外部到服务器），而其他数据中心可能会将两者结合起来。流量模式本质上可能是突发性的，包含多对一、多对多或一对多流量。当包含UDP和TCP流量的混合时，每个流也可能是小的、对延迟敏感的，或者是大的、对吞吐量敏感的。所有这些都可以在单个集群中共存，并同时流经单个网络设备。网络设备的基准测试长期以来一直使用[RFC1242]、[RFC2432]、[RFC2544]、[RFC2889]和[RFC3918]，这些测试主要集中在被基准测试设备（DUT）的各种延迟属性和吞吐量[RFC2889]上。这些标准擅长测量测试条件下的理论吞吐量、转发速率和延迟；然而，它们并不代表可能影响这些网络设备的真实流量模式。
Currently, typical data center networking devices are characterized by:
目前，典型的数据中心网络设备具有以下特点：
- High port density (48 ports or more).
- 高端口密度（48个或更多端口）。
- High speed (currently, up to 100 GB/s per port).
- 高速（目前，每个端口高达100 GB/s）。
- High throughput (line rate on all ports for Layer 2 and/or Layer 3).
- 高吞吐量（第2层和/或第3层的所有端口上的线路速率）。
- Low latency (in the microsecond or nanosecond range).
- 低延迟（在微秒或纳秒范围内）。
- Low amount of buffer (in the MB range per networking device).
- 缓冲区容量低（每个网络设备的MB范围内）。
- Layer 2 and Layer 3 forwarding capability (Layer 3 not mandatory).
- 第2层和第3层转发能力（第3层不是强制性的）。
This document provides a methodology for benchmarking data center physical network equipment DUTs, including congestion scenarios, switch buffer analysis, microburst, and head-of-line blocking, while also using a wide mix of traffic conditions. [RFC8238] is a prerequisite for this document, as it contains terminology that is considered normative.
本文档提供了一种对数据中心物理网络设备DUT进行基准测试的方法，包括拥塞场景、交换机缓冲区分析、微突发和线路端阻塞，同时还使用了多种流量条件。[RFC8238]是本文件的先决条件，因为其中包含被视为规范性的术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following format is used in Sections 2 through 6 of this document:
本文件第2节至第6节使用了以下格式：
- Objective
- 客观的
- Methodology
- 方法论
- Reporting Format
- 报告格式
For each test methodology described in this document, it is critical that repeatability of the results be obtained. The recommendation is to perform enough iterations of the given test and to make sure that the result is consistent. This is especially important in the context of the tests described in Section 3, as the buffering testing has historically been the least reliable. The number of iterations SHOULD be explicitly reported. The relative standard deviation SHOULD be below 10%.
对于本文件中描述的每种试验方法，获得结果的可重复性至关重要。建议对给定的测试执行足够的迭代，并确保结果一致。这在第3节所述的测试中尤其重要，因为缓冲测试在历史上是最不可靠的。应明确报告迭代次数。相对标准偏差应低于10%。
The objective of this test is to provide a "maximum rate" test for the performance values for throughput, latency, and jitter. It is meant to provide (1) the tests to perform and (2) methodology for verifying that a DUT is capable of forwarding packets at line rate under non-congested conditions.
此测试的目的是为吞吐量、延迟和抖动的性能值提供“最大速率”测试。其旨在提供（1）执行的测试和（2）验证DUT能够在非拥塞条件下以线路速率转发数据包的方法。
A traffic generator SHOULD be connected to all ports on the DUT. Two tests MUST be conducted: (1) a port-pair test [RFC2544] [RFC3918] and (2) a test using a full-mesh DUT [RFC2889] [RFC3918].
流量发生器应连接至DUT上的所有端口。必须进行两项测试：（1）端口对测试[RFC2544][RFC3918]和（2）使用全网状DUT[RFC2889][RFC3918]的测试。
For all tests, the traffic generator's sending rate MUST be less than or equal to 99.98% of the nominal value of the line rate (with no further Parts Per Million (PPM) adjustment to account for interface clock tolerances), to ensure stressing of the DUT in reasonable
对于所有测试，流量发生器的发送速率必须小于或等于线路速率标称值的99.98%（不考虑接口时钟公差的进一步百万分率（PPM）调整），以确保DUT的应力在合理范围内
worst-case conditions (see [RFC8238], Section 5 for more details). Test results at a lower rate MAY be provided for better understanding of performance increase in terms of latency and jitter when the rate is lower than 99.98%. The receiving rate of the traffic SHOULD be captured during this test as a percentage of line rate.
最坏情况（详见[RFC8238]，第5节）。当速率低于99.98%时，可提供较低速率下的测试结果，以便更好地了解延迟和抖动方面的性能增加。在该测试期间，应以线路速率的百分比捕获通信量的接收速率。
The test MUST provide the statistics of minimum, average, and maximum of the latency distribution, for the exact same iteration of the test.
对于完全相同的测试迭代，测试必须提供延迟分布的最小、平均和最大统计信息。
The test MUST provide the statistics of minimum, average, and maximum of the jitter distribution, for the exact same iteration of the test.
对于完全相同的测试迭代，测试必须提供抖动分布的最小值、平均值和最大值的统计信息。
Alternatively, when a traffic generator cannot be connected to all ports on the DUT, a snake test MUST be used for line-rate testing, excluding latency and jitter, as those would become irrelevant. The snake test is performed as follows:
或者，当流量生成器无法连接到DUT上的所有端口时，必须使用snake测试进行线速率测试，不包括延迟和抖动，因为这些将变得无关紧要。snake测试按如下方式进行：
- Connect the first and last port of the DUT to a traffic generator.
- 将DUT的第一个和最后一个端口连接到流量生成器。
- Connect, back to back and sequentially, all the ports in between: port 2 to port 3, port 4 to port 5, etc., to port N-2 to port N-1, where N is the total number of ports of the DUT.
- 按顺序背靠背连接两个端口之间的所有端口：端口2至端口3、端口4至端口5等，连接端口N-2至端口N-1，其中N是DUT的端口总数。
- Configure port 1 and port 2 in the same VLAN X, port 3 and port 4 in the same VLAN Y, etc., and port N-1 and port N in the same VLAN Z.
- 在同一VLAN X中配置端口1和端口2，在同一VLAN Y中配置端口3和端口4，等等，在同一VLAN Z中配置端口N-1和端口N。
This snake test provides the capability to test line rate for Layer 2 and Layer 3 [RFC2544] [RFC3918] in instances where a traffic generator with only two ports is available. Latency and jitter are not to be considered for this test.
此snake测试提供了在只有两个端口的流量生成器可用的情况下测试第2层和第3层[RFC2544][RFC3918]的线路速率的能力。本测试不考虑延迟和抖动。
The report MUST include the following:
报告必须包括以下内容：
- Physical-layer calibration information, as defined in [RFC8238], Section 4.
- 物理层校准信息，如[RFC8238]第4节所定义。
- Number of ports used.
- 使用的端口数。
- Reading for "throughput received as a percentage of bandwidth", while sending 99.98% of the nominal value of the line rate on each port, for each packet size from 64 bytes to 9216 bytes. As guidance, with a packet-size increment of 64 bytes between each iteration being ideal, 256-byte and 512-byte packets are also
- 读取“以带宽百分比表示的接收吞吐量”，同时发送每个端口上线路速率标称值的99.98%，每个数据包大小从64字节到9216字节。作为指导，由于每次迭代之间的数据包大小增量为64字节是理想的，因此还需要256字节和512字节的数据包
often used. The most common packet-size ordering for the report is 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes, 1518 bytes, 4096 bytes, 8000 bytes, and 9216 bytes.
经常使用。报告最常见的数据包大小顺序是64字节、128字节、256字节、512字节、1024字节、1518字节、4096字节、8000字节和9216字节。
The pattern for testing can be expressed using [RFC6985].
测试模式可以使用[RFC6985]表示。
- Throughput needs to be expressed as a percentage of total transmitted frames.
- 吞吐量需要表示为总传输帧的百分比。
- Packet drops MUST be expressed as a count of packets and SHOULD be expressed as a percentage of line rate.
- 数据包丢弃必须表示为数据包计数，并应表示为线路速率的百分比。
- For latency and jitter, values are expressed in units of time (usually microseconds or nanoseconds), reading across packet sizes from 64 bytes to 9216 bytes.
- 对于延迟和抖动，值以时间单位（通常为微秒或纳秒）表示，数据包大小从64字节到9216字节不等。
- For latency and jitter, provide minimum, average, and maximum values. If different iterations are done to gather the minimum, average, and maximum values, this SHOULD be specified in the report, along with a justification for why the information could not have been gathered in the same test iteration.
- 对于延迟和抖动，请提供最小值、平均值和最大值。如果进行了不同的迭代以收集最小值、平均值和最大值，则应在报告中对此进行指定，并说明为什么不能在同一测试迭代中收集信息。
- For jitter, a histogram describing the population of packets measured per latency or latency buckets is RECOMMENDED.
- 对于抖动，建议使用直方图描述每个延迟或延迟桶测量的数据包数量。
- The tests for throughput, latency, and jitter MAY be conducted as individual independent trials, with proper documentation provided in the report, but SHOULD be conducted at the same time.
- 吞吐量、延迟和抖动测试可以作为单独的独立试验进行，报告中提供了适当的文档，但应同时进行。
- The methodology assumes that the DUT has at least nine ports, as certain methodologies require nine or more ports.
- 该方法假设DUT至少有九个端口，因为某些方法需要九个或更多端口。
The objective of this test is to measure the size of the buffer of a DUT under typical/many/multiple conditions. Buffer architectures between multiple DUTs can differ and include egress buffering, shared egress buffering SoC (Switch-on-Chip), ingress buffering, or a combination thereof. The test methodology covers the buffer measurement, regardless of buffer architecture used in the DUT.
本试验的目的是在典型/多个/多个条件下测量DUT缓冲区的大小。多个DUT之间的缓冲体系结构可以不同，包括出口缓冲、共享出口缓冲SoC（片上开关）、入口缓冲或其组合。无论DUT中使用的缓冲区架构如何，测试方法涵盖缓冲区测量。
A traffic generator MUST be connected to all ports on the DUT. The methodology for measuring buffering for a data center switch is based on using known congestion of known fixed packet size, along with maximum latency value measurements. The maximum latency will increase until the first packet drop occurs. At this point, the maximum latency value will remain constant. This is the point of inflection of this maximum latency change to a constant value. There MUST be multiple ingress ports receiving a known amount of frames at a known fixed size, destined for the same egress port in order to create a known congestion condition. The total amount of packets sent from the oversubscribed port minus one, multiplied by the packet size, represents the maximum port buffer size at the measured inflection point.
流量发生器必须连接到DUT上的所有端口。测量数据中心交换机缓冲的方法基于使用已知固定数据包大小的已知拥塞以及最大延迟值测量。最大延迟将增加，直到发生第一次数据包丢弃。此时，最大延迟值将保持不变。这是最大延迟更改为常量值的拐点。必须有多个入口端口以已知的固定大小接收已知数量的帧，目的地为同一出口端口，以便创建已知的拥塞条件。从超额订阅端口发送的数据包总量减去1，乘以数据包大小，表示测量拐点处的最大端口缓冲区大小。
Note that the tests described in procedures 1), 2), 3), and 4) in this section have iterations called "first iteration", "second iteration", and "last iteration". The idea is to show the first two iterations so the reader understands the logic of how to keep incrementing the iterations. The last iteration shows the end state of the variables.
请注意，本节中步骤1）、2）、3）和4）中描述的测试具有称为“第一次迭代”、“第二次迭代”和“最后一次迭代”的迭代。其思想是展示前两个迭代，以便读者理解如何不断增加迭代的逻辑。最后一次迭代显示变量的结束状态。
1) Measure the highest buffer efficiency.
1) 测量最高的缓冲效率。
o First iteration: Ingress port 1 sending 64-byte packets at line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size of 64 bytes to egress port 2. Measure the buffer size value of the number of frames sent from the port sending the oversubscribed traffic up to the inflection point multiplied by the frame size.
o 第一次迭代：入口端口1以线路速率向出口端口2发送64字节的数据包，而端口3正在向出口端口2发送已知的低超额订阅流量（建议为1%），数据包大小为64字节。测量从发送超额订阅流量的端口发送到拐点的帧数的缓冲区大小值乘以帧大小。
o Second iteration: Ingress port 1 sending 65-byte packets at line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size of 65 bytes to egress port 2. Measure the buffer size value of the number of frames sent from the port sending the oversubscribed traffic up to the inflection point multiplied by the frame size.
o 第二次迭代：入口端口1以线路速率向出口端口2发送65字节的数据包，而端口3正以65字节的数据包大小向出口端口2发送已知的少量超额订阅流量（建议为1%）。测量从发送超额订阅流量的端口发送到拐点的帧数的缓冲区大小值乘以帧大小。
o Last iteration: Ingress port 1 sending packets of size B bytes at line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size of B bytes to egress port 2. Measure the buffer size value of the number of frames sent from the port sending the oversubscribed traffic up to the inflection point multiplied by the frame size.
o 最后一次迭代：入口端口1以线路速率向出口端口2发送大小为B字节的数据包，而端口3正在向出口端口2发送大小为B字节的已知少量超额订阅流量（建议为1%）。测量从发送超额订阅流量的端口发送到拐点的帧数的缓冲区大小值乘以帧大小。
When the B value is found to provide the largest buffer size, then size B allows the highest buffer efficiency.
当发现B值提供最大的缓冲区大小时，则大小B允许最高的缓冲区效率。
2) Measure maximum port buffer size.
2) 测量最大端口缓冲区大小。
At fixed packet size B as determined in procedure 1), for a fixed default Differentiated Services Code Point (DSCP) / Class of Service (CoS) value of 0 and for unicast traffic, proceed with the following:
在过程1）中确定的固定数据包大小B下，对于固定的默认区分服务代码点（DSCP）/服务类别（CoS）值0和单播流量，继续执行以下操作：
o First iteration: Ingress port 1 sending line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size to egress port 2. Measure the buffer size value by multiplying the number of extra frames sent by the frame size.
o 第一次迭代：入口端口1向出口端口2发送线路速率，而端口3向出口端口2发送具有相同数据包大小的已知少量超额订阅流量（建议为1%）。通过将发送的额外帧数乘以帧大小来测量缓冲区大小值。
o Second iteration: Ingress port 2 sending line rate to egress port 3, while port 4 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size to egress port 3. Measure the buffer size value by multiplying the number of extra frames sent by the frame size.
o 第二次迭代：入口端口2向出口端口3发送线路速率，而端口4向出口端口3发送具有相同数据包大小的已知少量超额订阅流量（建议为1%）。通过将发送的额外帧数乘以帧大小来测量缓冲区大小值。
o Last iteration: Ingress port N-2 sending line rate to egress port N-1, while port N is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size to egress port N. Measure the buffer size value by multiplying the number of extra frames sent by the frame size.
o 最后一次迭代：入口端口N-2向出口端口N-1发送线路速率，而端口N向出口端口N发送具有相同数据包大小的已知少量超额订阅流量（建议为1%）。通过将发送的额外帧数乘以帧大小来测量缓冲区大小值。
This test series MAY be repeated using all different DSCP/CoS values of traffic, and then using multicast traffic, in order to find out if there is any DSCP/CoS impact on the buffer size.
可以使用所有不同的DSCP/CoS流量值，然后使用多播流量，重复此测试系列，以确定是否对缓冲区大小有任何DSCP/CoS影响。
3) Measure maximum port pair buffer sizes.
3) 测量最大端口对缓冲区大小。
o First iteration: Ingress port 1 sending line rate to egress port 2, ingress port 3 sending line rate to egress port 4, etc. Ingress port N-1 and port N will oversubscribe, at 1% of line rate, egress port 2 and port 3, respectively. Measure the buffer size value by multiplying the number of extra frames sent by the frame size for each egress port.
o 第一次迭代：入口端口1向出口端口2发送线路速率，入口端口3向出口端口4发送线路速率，等等。入口端口N-1和端口N将分别以线路速率的1%超额订阅出口端口2和端口3。通过将发送的额外帧数乘以每个出口端口的帧大小来测量缓冲区大小值。
o Second iteration: Ingress port 1 sending line rate to egress port 2, ingress port 3 sending line rate to egress port 4, etc. Ingress port N-1 and port N will oversubscribe, at 1% of line rate, egress port 4 and port 5, respectively. Measure the buffer size value by multiplying the number of extra frames sent by the frame size for each egress port.
o 第二次迭代：入口端口1向出口端口2发送线路速率，入口端口3向出口端口4发送线路速率，等等。入口端口N-1和端口N将分别以线路速率的1%超额订阅出口端口4和端口5。通过将发送的额外帧数乘以每个出口端口的帧大小来测量缓冲区大小值。
o Last iteration: Ingress port 1 sending line rate to egress port 2, ingress port 3 sending line rate to egress port 4, etc. Ingress port N-1 and port N will oversubscribe, at 1% of line rate, egress port N-3 and port N-2, respectively. Measure the buffer size value by multiplying the number of extra frames sent by the frame size for each egress port.
o 最后一次迭代：入口端口1向出口端口2发送线路速率，入口端口3向出口端口4发送线路速率，等等。入口端口N-1和端口N将分别以线路速率的1%超额订阅出口端口N-3和端口N-2。通过将发送的额外帧数乘以每个出口端口的帧大小来测量缓冲区大小值。
This test series MAY be repeated using all different DSCP/CoS values of traffic and then using multicast traffic.
可以使用所有不同的DSCP/CoS流量值，然后使用多播流量，重复该测试系列。
4) Measure maximum DUT buffer size with many-to-one ports.
4) 使用多对一端口测量最大DUT缓冲区大小。
o First iteration: Ingress ports 1,2,... N-1 each sending [(1/[N-1])*99.98]+[1/[N-1]] % of line rate per port to egress port N.
o 第一次迭代：入口端口1,2，。。。N-1每个端口向出口端口N发送[（1/[N-1]）*99.98]+[1/[N-1]]%的线路速率。
o Second iteration: Ingress ports 2,... N each sending [(1/[N-1])*99.98]+[1/[N-1]] % of line rate per port to egress port 1.
o 第二次迭代：入口端口2，。。。N每个端口向出口端口1发送[（1/[N-1]）*99.98]+[1/[N-1]]%的线路速率。
o Last iteration: Ingress ports N,1,2...N-2 each sending [(1/[N-1])*99.98]+[1/[N-1]] % of line rate per port to egress port N-1.
o 最后一次迭代：入口端口N，1,2…N-2每个发送[（1/[N-1]）*99.98]+[1/[N-1]]%的线路速率到出口端口N-1。
This test series MAY be repeated using all different CoS values of traffic and then using multicast traffic.
可以使用所有不同的CoS流量值，然后使用多播流量，重复该测试系列。
Unicast traffic, and then multicast traffic, SHOULD be used in order to determine the proportion of buffer for the documented selection of tests. Also, the CoS value for the packets SHOULD be provided for each test iteration, as the buffer allocation size MAY differ per CoS value. It is RECOMMENDED that the ingress and egress ports be varied in a random but documented fashion in multiple tests in order to measure the buffer size for each port of the DUT.
应使用单播通信量，然后是多播通信量，以确定记录的测试选择的缓冲区比例。此外，应为每个测试迭代提供分组的CoS值，因为每个CoS值的缓冲区分配大小可能不同。建议在多个测试中以随机但有记录的方式改变入口和出口端口，以便测量DUT每个端口的缓冲区大小。
The report MUST include the following:
报告必须包括以下内容：
- The packet size used for the most efficient buffer used, along with the DSCP/CoS value.
- 用于使用的最有效缓冲区的数据包大小以及DSCP/CoS值。
- The maximum port buffer size for each port.
- 每个端口的最大端口缓冲区大小。
- The maximum DUT buffer size.
- 最大DUT缓冲区大小。
- The packet size used in the test.
- 测试中使用的数据包大小。
- The amount of oversubscription, if different than 1%.
- 超额认购的金额，如果不同于1%。
- The number of ingress and egress ports, along with their location on the DUT.
- 入口和出口端口的数量及其在DUT上的位置。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results for each of the tests (min, max, avg).
- 需要指出测试的重复性：同一测试的迭代次数以及每个测试结果之间的变化百分比（最小值、最大值、平均值）。
The percentage of variation is a metric providing a sense of how big the difference is between the measured value and the previous values.
变化百分比是一种度量，它提供了测量值与先前值之间差异有多大的感觉。
For example, for a latency test where the minimum latency is measured, the percentage of variation (PV) of the minimum latency will indicate by how much this value has varied between the current test executed and the previous one.
例如，对于测量最小延迟的延迟测试，最小延迟的变化百分比（PV）将指示该值在当前执行的测试和前一个测试之间的变化程度。
PV = ((x2-x1)/x1)*100, where x2 is the minimum latency value in the
current test and x1 is the minimum latency value obtained in the
previous test.
PV = ((x2-x1)/x1)*100, where x2 is the minimum latency value in the
current test and x1 is the minimum latency value obtained in the
previous test.
The same formula is used for maximum and average variations measured.
相同的公式用于测量的最大和平均变化。
The objective of this test is to find the maximum amount of packet bursts that a DUT can sustain under various configurations.
该测试的目的是找出DUT在各种配置下能够承受的最大数据包突发量。
This test provides additional methodology that supplements the tests described in [RFC1242], [RFC2432], [RFC2544], [RFC2889], and [RFC3918].
该测试提供了补充[RFC1242]、[RFC2432]、[RFC2544]、[RFC2889]和[RFC3918]中所述测试的附加方法。
- All bursts should be sent with 100% intensity. Note: "Intensity" is defined in [RFC8238], Section 6.1.1.
- 所有爆发都应以100%的强度发送。注：“强度”定义见[RFC8238]第6.1.1节。
- All ports of the DUT must be used for this test.
- 此测试必须使用DUT的所有端口。
- It is recommended that all ports be tested simultaneously.
- 建议同时测试所有端口。
A traffic generator MUST be connected to all ports on the DUT. In order to cause congestion, two or more ingress ports MUST send bursts of packets destined for the same egress port. The simplest of the setups would be two ingress ports and one egress port (2 to 1).
流量发生器必须连接到DUT上的所有端口。为了造成拥塞，两个或多个入口端口必须发送指向同一出口端口的突发数据包。最简单的设置是两个入口端口和一个出口端口（2到1）。
The burst MUST be sent with an intensity (as defined in [RFC8238], Section 6.1.1) of 100%, meaning that the burst of packets will be sent with a minimum interpacket gap. The amount of packets contained in the burst will be trial variable and increase until there is a non-zero packet loss measured. The aggregate amount of packets from all the senders will be used to calculate the maximum microburst amount that the DUT can sustain.
突发必须以100%的强度（如[RFC8238]第6.1.1节所定义）发送，这意味着分组突发将以最小的分组间隔发送。突发中包含的数据包数量将是试验变量，并会增加，直到测量到非零数据包丢失。来自所有发送方的数据包总量将用于计算DUT能够承受的最大微脉冲量。
It is RECOMMENDED that the ingress and egress ports be varied in multiple tests in order to measure the maximum microburst capacity.
建议在多次试验中改变入口和出口，以测量最大微爆发能力。
The intensity of a microburst (see [RFC8238], Section 6.1.1) MAY be varied in order to obtain the microburst capacity at various ingress rates.
微爆发的强度（见[RFC8238]，第6.1.1节）可以改变，以获得不同进入速率下的微爆发能力。
It is RECOMMENDED that all ports on the DUT be tested simultaneously, and in various configurations, in order to understand all the combinations of ingress ports, egress ports, and intensities.
建议在各种配置下同时测试DUT上的所有端口，以了解入口端口、出口端口和强度的所有组合。
An example would be:
例如：
o First iteration: N-1 ingress ports sending to one egress port.
o 第一次迭代：N-1个入口端口发送到一个出口端口。
o Second iteration: N-2 ingress ports sending to two egress ports.
o 第二次迭代：N-2个入口端口发送到两个出口端口。
o Last iteration: Two ingress ports sending to N-2 egress ports.
o 最后一次迭代：两个入口端口发送到N-2个出口端口。
The report MUST include the following:
报告必须包括以下内容：
- The maximum number of packets received per ingress port with the maximum burst size obtained with zero packet loss.
- 每个入口端口接收的最大数据包数，具有在零数据包丢失情况下获得的最大突发大小。
- The packet size used in the test.
- 测试中使用的数据包大小。
- The number of ingress and egress ports, along with their location on the DUT.
- 入口和出口端口的数量及其在DUT上的位置。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results (min, max, avg).
- 需要指出测试的重复性：相同测试的迭代次数和结果之间的变化百分比（最小值、最大值、平均值）。
Head-of-line blocking (HOLB) is a performance-limiting phenomenon that occurs when packets are held up by the first packet ahead waiting to be transmitted to a different output port. This is defined in RFC 2889, Section 5.5 ("Congestion Control"). This section expands on RFC 2889 in the context of data center benchmarking.
行首阻塞（Head of line blocking，HOLB）是一种性能限制现象，当数据包被等待传输到不同输出端口的前一个数据包阻塞时会发生这种现象。这在RFC 2889第5.5节（“拥塞控制”）中有定义。本节在数据中心基准测试的背景下对RFC 2889进行了扩展。
The objective of this test is to understand the DUT's behavior in the HOLB scenario and measure the packet loss.
本测试的目的是了解DUT在HOLB场景中的行为，并测量数据包丢失。
The differences between this HOLB test and RFC 2889 are as follows:
本HOLB测试与RFC 2889之间的差异如下：
- This HOLB test starts with eight ports in two groups of four ports each, instead of four ports (as compared with Section 5.5 of RFC 2889).
- 该HOLB测试从两组八个端口开始，每组四个端口，而不是四个端口（与RFC 2889第5.5节相比）。
- This HOLB test shifts all the port numbers by one in a second iteration of the test; this is new, as compared to the HOLB test described in RFC 2889. The shifting port numbers continue until all ports are the first in the group; the purpose of this is to make sure that all permutations are tested in order to cover differences in behavior in the SoC of the DUT.
- 在测试的第二次迭代中，该HOLB测试将所有端口号移动1；与RFC 2889中描述的HOLB测试相比，这是一个新的测试。移动端口号持续，直到所有端口都是组中的第一个端口；其目的是确保测试所有排列，以涵盖DUT SoC中的行为差异。
- Another test within this HOLB test expands the group of ports, such that traffic is divided among four ports instead of two (25% instead of 50% per port).
- 此HOLB测试中的另一个测试扩展了端口组，这样，通信量将在四个端口而不是两个端口之间分配（每个端口25%而不是50%）。
- Section 5.3 lists requirements that supplement the requirements listed in RFC 2889, Section 5.5.
- 第5.3节列出了补充RFC 2889第5.5节所列要求的要求。
In order to cause congestion in the form of HOLB, groups of four ports are used. A group has two ingress ports and two egress ports. The first ingress port MUST have two flows configured, each going to a different egress port. The second ingress port will congest the second egress port by sending line rate. The goal is to measure if there is loss on the flow for the first egress port, which is not oversubscribed.
为了以HOLB的形式造成拥塞，使用了由四个端口组成的组。一个组有两个入口端口和两个出口端口。第一个入口端口必须配置两个流，每个流流向不同的出口端口。第二个入口端口将通过发送线路速率阻塞第二个出口端口。目标是测量第一个出口的流量是否有损失，但没有超额认购。
A traffic generator MUST be connected to at least eight ports on the DUT and SHOULD be connected using all the DUT ports.
流量发生器必须连接至DUT上的至少八个端口，并应使用所有DUT端口进行连接。
Note that the tests described in procedures 1) and 2) in this section have iterations called "first iteration", "second iteration", and "last iteration". The idea is to show the first two iterations so the reader understands the logic of how to keep incrementing the iterations. The last iteration shows the end state of the variables.
请注意，本节程序1）和2）中描述的测试具有称为“第一次迭代”、“第二次迭代”和“最后一次迭代”的迭代。其思想是展示前两个迭代，以便读者理解如何不断增加迭代的逻辑。最后一次迭代显示变量的结束状态。
1) Measure two groups with eight DUT ports.
1) 用八个DUT端口测量两组。
o First iteration: Measure the packet loss for two groups with consecutive ports.
o 第一次迭代：测量具有连续端口的两个组的数据包丢失。
The composition of the first group is as follows:
第一组的组成如下：
Ingress port 1 sending 50% of traffic to egress port 3 and ingress port 1 sending 50% of traffic to egress port 4. Ingress port 2 sending line rate to egress port 4. Measure the amount of traffic loss for the traffic from ingress port 1 to egress port 3.
入口端口1将50%的流量发送到出口端口3，入口端口1将50%的流量发送到出口端口4。入口端口2向出口端口4发送线路速率。测量从入口端口1到出口端口3的流量损失量。
The composition of the second group is as follows:
第二组的组成如下：
Ingress port 5 sending 50% of traffic to egress port 7 and ingress port 5 sending 50% of traffic to egress port 8. Ingress port 6 sending line rate to egress port 8. Measure the amount of traffic loss for the traffic from ingress port 5 to egress port 7.
入口端口5将50%的流量发送到出口端口7，入口端口5将50%的流量发送到出口端口8。入口端口6向出口端口8发送线路速率。测量从入口端口5到出口端口7的流量损失量。
o Second iteration: Repeat the first iteration by shifting all the ports from N to N+1.
o 第二次迭代：通过将所有端口从N移动到N+1，重复第一次迭代。
The composition of the first group is as follows:
第一组的组成如下：
Ingress port 2 sending 50% of traffic to egress port 4 and ingress port 2 sending 50% of traffic to egress port 5. Ingress port 3 sending line rate to egress port 5. Measure the amount of traffic loss for the traffic from ingress port 2 to egress port 4.
入口端口2将50%的流量发送到出口端口4，入口端口2将50%的流量发送到出口端口5。入口端口3向出口端口5发送线路速率。测量从入口端口2到出口端口4的流量损失量。
The composition of the second group is as follows:
第二组的组成如下：
Ingress port 6 sending 50% of traffic to egress port 8 and ingress port 6 sending 50% of traffic to egress port 9. Ingress port 7 sending line rate to egress port 9. Measure the amount of traffic loss for the traffic from ingress port 6 to egress port 8.
入口端口6将50%的流量发送到出口端口8，入口端口6将50%的流量发送到出口端口9。入口端口7向出口端口9发送线路速率。测量从入口端口6到出口端口8的流量损失量。
o Last iteration: When the first port of the first group is connected to the last DUT port and the last port of the second group is connected to the seventh port of the DUT.
o 最后一次迭代：当第一组的第一个端口连接到最后一个DUT端口，第二组的最后一个端口连接到DUT的第七个端口时。
Measure the amount of traffic loss for the traffic from ingress port N to egress port 2 and from ingress port 4 to egress port 6.
测量从入口端口N到出口端口2以及从入口端口4到出口端口6的流量损失量。
2) Measure with N/4 groups with N DUT ports.
2) 使用N/4组和N个DUT端口进行测量。
The traffic from the ingress port is split across four egress ports (100/4 = 25%).
来自入口端口的流量被分成四个出口端口（100/4=25%）。
o First iteration: Expand to fully utilize all the DUT ports in increments of four. Repeat the methodology of procedure 1) with all the groups of ports possible to achieve on the device, and measure the amount of traffic loss for each port group.
o 第一次迭代：以四个为增量扩展以充分利用所有DUT端口。对设备上可能实现的所有端口组重复步骤1）的方法，并测量每个端口组的流量损失量。
o Second iteration: Shift by +1 the start of each consecutive port of the port groups.
o 第二次迭代：按+1移位端口组中每个连续端口的开始。
o Last iteration: Shift by N-1 the start of each consecutive port of the port groups, and measure the amount of traffic loss for each port group.
o 最后一次迭代：按N-1移位端口组中每个连续端口的开始，并测量每个端口组的流量损失量。
For each test, the report MUST include the following:
对于每个测试，报告必须包括以下内容：
- The port configuration, including the number and location of ingress and egress ports located on the DUT.
- 端口配置，包括位于DUT上的入口和出口端口的数量和位置。
- If HOLB was observed in accordance with the HOLB test described in Section 5.
- 如果根据第5节所述的HOLB试验观察到HOLB。
- Percent of traffic loss.
- 交通损失的百分比。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results (min, max, avg).
- 需要指出测试的重复性：相同测试的迭代次数和结果之间的变化百分比（最小值、最大值、平均值）。
The objective of this test is to measure the values for TCP Goodput [TCP-INCAST] and latency with a mix of large and small flows. The test is designed to simulate a mixed environment of stateful flows that require high rates of goodput and stateless flows that require low latency. Stateful flows are created by generating TCP traffic, and stateless flows are created using UDP traffic.
此测试的目的是测量TCP Goodput[TCP-INCAST]和大小流混合时的延迟值。该测试旨在模拟一个混合环境，其中有状态流需要较高的goodput速率，无状态流需要较低的延迟。有状态流是通过生成TCP流量创建的，无状态流是使用UDP流量创建的。
In order to simulate the effects of stateless and stateful traffic on the DUT, there MUST be multiple ingress ports receiving traffic 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 two ingress ports receiving traffic destined to the same egress port.
为了模拟DUT上的无状态和有状态流量的影响，必须有多个入口端口接收发送给同一出口端口的流量。还可能存在到达单个入口端口的有状态和无状态流量的混合。最简单的设置是两个入口端口，接收发送到同一出口端口的流量。
One ingress port MUST maintain a TCP connection through the 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 through the DUT, and the stateless traffic is sent destined to a receiver on the same egress port. The stateless traffic MUST be a microburst of 100% intensity.
一个入口端口必须通过入口端口与连接到出口端口的接收器保持TCP连接。TCP流中的流量必须以流量生成器允许的最大速率发送。同时，TCP流量流经DUT，无状态流量被发送到同一出口端口上的接收器。无状态流量必须是100%强度的微爆发。
It is RECOMMENDED that the ingress and egress ports be varied in multiple tests in order to measure the maximum microburst capacity.
建议在多次试验中改变入口和出口，以测量最大微爆发能力。
The intensity of a microburst MAY be varied in order to obtain the microburst capacity at various ingress rates.
微爆发的强度可以改变，以便在各种进入速率下获得微爆发能力。
It is RECOMMENDED that all ports on the DUT be used in the test.
建议在测试中使用DUT上的所有端口。
The tests described below have iterations called "first iteration", "second iteration", and "last iteration". The idea is to show the first two iterations so the reader understands the logic of how to keep incrementing the iterations. The last iteration shows the end state of the variables.
下面描述的测试具有称为“第一次迭代”、“第二次迭代”和“最后一次迭代”的迭代。其思想是展示前两个迭代，以便读者理解如何不断增加迭代的逻辑。最后一次迭代显示变量的结束状态。
For example:
例如：
Stateful traffic port variation (TCP traffic):
有状态流量端口变化（TCP流量）：
TCP traffic needs to be generated for this test. During the iterations, the number of egress ports MAY vary as well.
此测试需要生成TCP通信量。在迭代期间，出口端口的数量也可能有所不同。
o First iteration: One ingress port receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 第一次迭代：一个入口端口接收有状态TCP流量，一个入口端口接收目的地为一个出口端口的无状态流量。
o Second iteration: Two ingress ports receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 第二次迭代：两个入口端口接收有状态TCP流量，一个入口端口接收目的地为一个出口端口的无状态流量。
o Last iteration: N-2 ingress ports receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 最后一次迭代：N-2个入口端口接收有状态TCP流量，一个入口端口接收目的地为一个出口端口的无状态流量。
Stateless traffic port variation (UDP traffic):
无状态通信端口变化（UDP通信）：
UDP traffic needs to be generated for this test. During the iterations, the number of egress ports MAY vary as well.
此测试需要生成UDP通信量。在迭代期间，出口端口的数量也可能有所不同。
o First iteration: One ingress port receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 第一次迭代：一个入口端口接收有状态TCP流量，一个入口端口接收目的地为一个出口端口的无状态流量。
o Second iteration: One ingress port receiving stateful TCP traffic and two ingress ports receiving stateless traffic destined to one egress port.
o 第二次迭代：一个入口端口接收有状态TCP流量，两个入口端口接收目的地为一个出口端口的无状态流量。
o Last iteration: One ingress port receiving stateful TCP traffic and N-2 ingress ports receiving stateless traffic destined to one egress port.
o 最后一次迭代：一个入口端口接收有状态TCP流量，N-2个入口端口接收目的地为一个出口端口的无状态流量。
The report MUST include the following:
报告必须包括以下内容：
- Number of ingress and egress ports, along with designation of stateful or stateless flow assignment.
- 入口和出口端口的数量，以及有状态或无状态流分配的指定。
- Stateful flow goodput.
- 有状态流输出。
- Stateless flow latency.
- 无状态流延迟。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results (min, max, avg).
- 需要指出测试的重复性：相同测试的迭代次数和结果之间的变化百分比（最小值、最大值、平均值）。
Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
本备忘录中所述的基准测试活动仅限于在实验室环境中使用受控刺激进行技术表征，具有专用地址空间和上述章节中规定的约束条件。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
基准网络拓扑将是一个独立的测试设置，不得连接到可能将测试流量转发到生产网络或将流量错误路由到测试管理网络的设备。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT.
此外，基准测试是在“黑盒”的基础上进行的，仅依赖于DUT外部可观察到的测量。
Special capabilities SHOULD NOT exist in the DUT specifically for benchmarking purposes. Any implications for network security arising from the DUT SHOULD be identical in the lab and in production networks.
DUT中不应存在专门用于基准测试的特殊能力。在实验室和生产网络中，DUT对网络安全的影响应相同。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.
[RFC1242]Bradner，S.，“网络互连设备的基准术语”，RFC 1242，DOI 10.17487/RFC1242，1991年7月<https://www.rfc-editor.org/info/rfc1242>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.
[RFC2544]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，DOI 10.17487/RFC2544，1999年3月<https://www.rfc-editor.org/info/rfc2544>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8238] Avramov, L. and J. Rapp, "Data Center Benchmarking Terminology", RFC 8238, DOI 10.17487/RFC8238, August 2017, <https://www.rfc-editor.org/info/rfc8238>.
[RFC8238]Avramov，L.和J.Rapp，“数据中心基准术语”，RFC 8238，DOI 10.17487/RFC8238，2017年8月<https://www.rfc-editor.org/info/rfc8238>.
[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, DOI 10.17487/RFC2432, October 1998, <https://www.rfc-editor.org/info/rfc2432>.
[RFC2432]Dubrey，K.，“IP多播基准测试术语”，RFC 2432，DOI 10.17487/RFC2432，1998年10月<https://www.rfc-editor.org/info/rfc2432>.
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, DOI 10.17487/RFC2889, August 2000, <https://www.rfc-editor.org/info/rfc2889>.
[RFC2889]Mandeville，R.和J.Perser，“局域网交换设备的基准测试方法”，RFC 2889，DOI 10.17487/RFC2889，2000年8月<https://www.rfc-editor.org/info/rfc2889>.
[RFC3918] Stopp, D. and B. Hickman, "Methodology for IP Multicast Benchmarking", RFC 3918, DOI 10.17487/RFC3918, October 2004, <https://www.rfc-editor.org/info/rfc3918>.
[RFC3918]Stopp，D.和B.Hickman，“IP多播基准测试方法”，RFC 3918，DOI 10.17487/RFC3918，2004年10月<https://www.rfc-editor.org/info/rfc3918>.
[RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet Sizes for Additional Testing", RFC 6985, DOI 10.17487/RFC6985, July 2013, <https://www.rfc-editor.org/info/rfc6985>.
[RFC6985]Morton，A.，“IMIX基因组：用于附加测试的可变数据包大小规范”，RFC 6985，DOI 10.17487/RFC6985，2013年7月<https://www.rfc-editor.org/info/rfc6985>.
[TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, "Understanding TCP Incast and Its Implications for Big Data Workloads", April 2012, <http://yanpeichen.com/ professional/usenixLoginIncastReady.pdf>.
[TCP-INCAST]Chen，Y.，Griffith，R.，Zats，D.，Joseph，A.，和R.Katz，“理解TCP-INCAST及其对大数据工作负载的影响”，2012年4月<http://yanpeichen.com/ professional/UseNixLoginCastReady.pdf>。
Acknowledgments
致谢
The authors would like to thank Al Morton and Scott Bradner for their reviews and feedback.
作者要感谢Al Morton和Scott Bradner的评论和反馈。
Authors' Addresses
作者地址
Lucien Avramov Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Lucien Avramov谷歌1600圆形剧场公园路山景，加利福尼亚州94043美利坚合众国
Email: lucien.avramov@gmail.com
Email: lucien.avramov@gmail.com
Jacob Rapp VMware 3401 Hillview Ave. Palo Alto, CA 94304 United States of America
美国加利福尼亚州帕洛阿尔托市Hillview大道3401号，邮编94304
Email: jhrapp@gmail.com
Email: jhrapp@gmail.com