数据中心基准测试方法

RFC8239：Data Center Benchmarking Methodology，August 2017

梗概

本信息文档的目的是为数据中心的物理网络设备建立测试和评估方法以及测量技术。RFC 8238（数据中心基准测试术语） 是本文档的先决条件，因为它包含被视为规范的术语。由于最初应用于数据中心的技术已部署在其他地方，因此其中许多术语和方法可能适用于本文档的范围之外。

本备忘录的状态

本文档不是 Internet Standards Track 规范；它是为了提供信息而发布的。

本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。并非 IESG 批准的所有文件都适用于任何级别的互联网标准；请参阅 RFC 7841 的第 2 节。

有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc8239。

版权声明

版权所有 (c) 2017 IETF Trust 和文件作者。版权所有。

本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。

1、 简介

数据中心的流量模式并不统一，并且在不断变化。它们取决于数据中心使用的应用程序的性质和种类。它们可以是一个数据中心的主要东西向流量（数据中心内的服务器到服务器）和另一个数据中心的南北向流量（从数据中心外部到服务器），而其他流量可能将两者结合起来。流量模式本质上可能是突发的，并且包含多对一、多对多或一对多的流量。每个流在包含 UDP 和 TCP 流量的混合时，也可能很小且对延迟敏感或较大且对吞吐量敏感。所有这些都可以共存于单个集群中，并同时流经单个网络设备。网络设备的基准测试长期以来一直使用 [RFC1242]、[RFC2432]、[RFC2544]、[RFC2889] 和 [RFC3918]，它们主要集中在被测设备 (Device Under Test，DUT) 的各种延迟属性和吞吐量 [RFC2889] ) 进行基准测试。这些标准擅长测量测试条件下的理论吞吐量、转发率和延迟；但是，它们并不代表可能影响这些网络设备的真实流量模式。

目前，典型的数据中心组网设备具有以下特点：

- 高端口密度（48 个或更多端口）。

- 高速（目前，每个端口高达 100 GB/s）。

- 高吞吐量（二层和/或三层的所有端口上的线速）。

- 低延迟（在微秒或纳秒范围内）。

- 缓冲区空间小（在每个网络设备的 MB 范围内）。

- 二层和三层转发能力（三层不是强制性的）。

本文档提供了一种方法，用于对数据中心物理网络设备 DUT 进行基准测试，包括拥塞场景、交换机缓冲区分析、微突发和队头阻塞，同时还使用各种流量条件。[RFC8238] 是本文档的先决条件，因为它包含被认为是规范的术语。

1.1、 需求语言

关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写字母出现时，本文档中的 " 将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。

1.2、 方法学格式和可重复性建议

本文档的第 2 至 6 节使用以下格式：

- 目标

- 方法

- 报告格式

对于本文档中描述的每种测试方法，获得结果的可重复性至关重要。建议是对给定的测试执行足够的迭代，并确保结果是一致的。这在第 3 节中描述的测试的上下文中尤其重要，因为缓冲测试历来是最不可靠的。应该明确报告迭代次数。相对标准偏差应低于 10%。

2、 线速测试

2.1、 目标

该测试的目的是为吞吐量、延迟和抖动的性能值提供“最大速率”测试。它旨在提供 (1) 要执行的测试和 (2) 验证 DUT 能够在非拥塞条件下以线速转发数据包的方法。

2.2、 方法

应将流量发生器连接到 DUT 上的所有端口。必须进行两项测试：(1) 端口对测试 [RFC2544] [RFC3918] 和 (2) 使用全互联 DUT [RFC2889] [RFC3918] 的测试。

对于所有测试，流量发生器的发送速率必须小于或等于线速标称值的 99.98%（没有进一步的百万分率 (Parts Per Million，PPM) 调整以考虑接口时钟容差），以确保对DUT 在合理的最坏情况条件下（参见 [RFC8238]，第 5 节了解更多详细信息）。当速率低于 99.98% 时，可以提供较低速率的测试结果，以便更好地了解延迟和抖动方面的性能增加。在此测试期间应捕获流量的接收速率，作为线速的百分比。

对于完全相同的测试迭代，测试必须提供延迟分布的最小值、平均值和最大值的统计信息。

测试必须为完全相同的测试迭代提供抖动分布的最小值、平均值和最大值的统计信息。

或者，当流量发生器无法连接到 DUT 上的所有端口时，必须使用蛇形测试进行线速测试，不包括延迟和抖动，因为这些将变得无关紧要。蛇形测试执行如下：

- 将 DUT 的第一个和最后一个端口连接到流量发生器。

- 背靠背顺序连接中间的所有端口：端口 2 到端口 3，端口 4 到端口 5，等等，端口 N-2 到端口 N-1，其中 N 是端口的总数被测设备。

- 配置端口1和端口2在同一个VLAN X，端口3和端口4在同一个VLAN Y等，端口N-1和端口N在同一个VLAN Z。

在只有两个端口的流量生成器可用的情况下，此蛇形测试提供了测试二层和三层 [RFC2544] [RFC3918] 的线速的能力。此测试不考虑延迟和抖动。

2.3、 报告格式

报告必须包括以下内容：

- 物理层校准信息，如 [RFC8238] 第 4 节中所定义。

- 使用的端口数。

- 读取“作为带宽百分比接收的吞吐量”，同时在每个端口上发送 99.98% 的线速标称值，每个数据包大小从 64 字节到 9216 字节。作为指导，每次迭代之间的数据包大小增量为 64 字节是理想的，也经常使用 256 字节和 512 字节的数据包。报告中最常见的数据包大小排序为 64 字节、128 字节、256 字节、512 字节、1024 字节、1518 字节、4096 字节、8000 字节和 9216 字节。

测试模式可以使用 [RFC6985] 来表达。

- 吞吐量需要表示为总传输帧的百分比。

- 丢包必须表示为数据包计数，并且应该表示为线速的百分比。

- 对于延迟和抖动，值以时间单位（通常为微秒或纳秒）表示，读取的数据包大小从 64 字节到 9216 字节。

- 对于延迟和抖动，提供最小值、平均值和最大值。如果进行不同的迭代以收集最小值、平均值和最大值，则应在报告中指定这一点，并说明为什么无法在同一测试迭代中收集信息的理由。

- 对于抖动，建议使用直方图描述每个延迟或延迟桶测量的数据包数量。

- 吞吐量、延迟和抖动的测试可以作为单独的独立试验进行，报告中提供了适当的文档，但应该同时进行。

- 该方法假设 DUT 至少有 9 个端口，因为某些方法需要 9 个或更多端口。

3、 缓冲测试

3.1、 目标

该测试的目的是在典型/多/复合条件下测量 DUT 的缓冲区大小。多个 DUT 之间的缓冲器架构可能不同，包括出口缓冲、共享出口缓冲 SoC（Switch-on-Chip，片上交换机）、入口缓冲或其组合。测试方法涵盖了缓冲器测量，与 DUT 中使用的缓冲器架构无关。

3.2、 方法

流量发生器必须连接到 DUT 上的所有端口。测量数据中心交换机缓冲的方法基于使用已知固定数据包大小的已知拥塞以及最大延迟值测量。最大延迟将增加，直到发生第一个数据包丢弃。此时，最大延迟值将保持不变。这是这个最大延迟变化到一个恒定值的拐点。必须有多个入口端口以已知的固定大小接收已知数量的帧，发往相同的出口端口，以创建已知的拥塞条件。从超额订阅端口发送的数据包总量减一，乘以数据包大小，表示在测量的拐点处的最大端口缓冲区大小。

请注意，本节中过程 1)、2)、3) 和 4) 中描述的测试具有称为“第一次迭代”、“第二次迭代”和“最后一次迭代”的迭代。这个想法是展示前两次迭代，以便读者理解如何不断增加迭代的逻辑。最后一次迭代显示了变量的结束状态。

1) 测量最高缓冲效率。

*第一次迭代：入口端口 1 以线速向出口端口 2 发送 64 字节数据包，而端口 3 向出口端口 2 发送已知的少量超额订阅流量（推荐 1%），数据包大小相同，为 64 字节。测量从发送超订流量的端口发送到拐点的帧数乘以帧大小的缓冲区大小值。

*第二次迭代：入口端口 1 以线速向出口端口 2 发送 65 字节数据包，而端口 3 向出口端口 2 发送已知的少量超额订阅流量（推荐 1%），数据包大小相同，为 65 字节。测量从发送超订流量的端口发送到拐点的帧数乘以帧大小的缓冲区大小值。

*最后一次迭代：入口端口 1 以线速向出口端口 2 发送大小为 B 字节的数据包，而端口 3 正在向出口端口2发送已知的少量超额订阅流量（推荐 1%），数据包大小相同，为 B 字节。测量从发送超订流量的端口发送到拐点的帧数乘以帧大小的缓冲区大小值。

当发现 B 值提供最大的缓冲区大小时，则大小 B 允许最高的缓冲区效率。

2) 测量最大端口缓冲区大小。

在程序 1) 中确定的固定数据包大小 B 下，对于固定的默认差分服务代码点 (Differentiated Services Code Point，DSCP)/服务等级 (Class of Service，CoS) 值为 0 的单播流量，请继续执行以下操作：

*第一次迭代：入口端口 1 向出口端口 2 发送线速，而端口 3 向出口端口 2 发送具有相同数据包大小的已知少量超额订阅流量（推荐 1%）。通过乘以测量缓冲区大小值帧大小发送的额外帧数。

*第二次迭代：入口端口 2 向出口端口 3 发送线速，而端口 4 向出口端口 3 发送具有相同数据包大小的已知少量超额订阅流量（推荐 1%）。通过乘以测量缓冲区大小值帧大小发送的额外帧数。

*最后一次迭代：入口端口 N-2 向出口端口 N-1 发送线速，而端口 N 正在向出口端口 N 发送具有相同数据包大小的已知少量超额订阅流量（推荐 1%）。测量缓冲区大小值乘以帧大小发送的额外帧数。

可以使用所有不同的 DSCP/CoS 流量值重复此测试系列，然后使用组播流量，以查明 DSCP/CoS 是否对缓冲区大小产生影响。

3) 测量最大端口对缓冲区大小。

*第一次迭代：入口端口 1 向出口端口 2 发送线速，入口端口 3 向出口端口 4 发送线速，等等。入口端口 N-1 和端口 N 将以线速的 1% 超额订阅，出口端口 2和端口 3，分别。通过将发送的额外帧数乘以每个出口端口的帧大小来测量缓冲区大小值。

*第二次迭代：入口端口 1 向出口端口 2 发送线速，入口端口 3 向出口端口 4 发送线速，等等。入口端口 N-1 和端口 N 将以线速的 1% 超额订阅，出口端口 4和端口 5，分别。通过将发送的额外帧数乘以每个出口端口的帧大小来测量缓冲区大小值。

*最后一次迭代：入口端口 1 向出口端口 2 发送线速，入口端口 3 向出口端口 4 发送线速，等等。入口端口 N-1 和端口 N 将以线速的 1% 超额订阅，出口端口 N -3 和端口 N-2，分别。通过将发送的额外帧数乘以每个出口端口的帧大小来测量缓冲区大小值。

可以使用所有不同的 DSCP/CoS 流量值重复此测试系列，然后使用组播流量。

4) 使用多对一端口测量最大 DUT 缓冲区大小。

*第一次迭代：入口端口 1,2,... N-1 每个端口发送百分之[(1/[N-1])*99.98]+[1/[N-1]] 的线速到出口端口 N。

*第二次迭代：入口端口 2，... N 每个端口向出口端口 1 发送每个端口的百分之[(1/[N-1])*99.98]+[1/[N-1]] 的线速。

*最后一次迭代：入口端口 N,1,2...N-2 每个端口发送百分之[(1/[N-1])*99.98]+[1/[N-1]] 的线速到出口端口 N-1。

可以使用所有不同的 CoS 流量值重复此测试系列，然后使用组播流量。

应该使用单播流量，然后是组播流量，以确定记录在案的测试选择的缓冲区比例。此外，应该为每次测试迭代提供数据包的 CoS 值，因为每个 CoS 值的缓冲区分配大小可能不同。建议在多次测试中以随机但记录的方式改变入口和出口端口，以便测量 DUT 每个端口的缓冲区大小。

3.3、 报告格式

报告必须包括以下内容：

- 用于最有效缓冲区的数据包大小，以及 DSCP/CoS 值。

- 每个端口的最大端口缓冲区大小。

- 最大 DUT 缓冲区大小。

- 测试中使用的数据包大小。

- 超额订阅量，如果不同于 1%。

- 入口和出口端口的数量，以及它们在 DUT 上的位置。

- 需要说明测试的可重复性：同一测试的迭代次数和每个测试结果之间的变化百分比（最小值、最大值、平均值）。

变化百分比是一种度量，它提供了测量值与先前值之间的差异有多大的感觉。

例如，对于测量最小延迟的延迟测试，最小延迟的变化百分比 (percentage of variation，PV) 将指示该值在当前执行的测试和前一个测试之间变化了多少。

PV = ((x2-x1)/x1)*100，其中x2是当前测试中的最小延迟值，x1是之前测试中得到的最小延迟值。

相同的公式用于测量的最大和平均变化。

4、 微突发测试

4.1、 目标

该测试的目的是找出 DUT 在各种配置下可以承受的最大数据包突发量。

该测试提供了补充 [RFC1242]、[RFC2432]、[RFC2544]、[RFC2889] 和 [RFC3918] 中描述的测试的附加方法。

- 所有突发都应以 100% 的强度发送。注意：“强度”在 [RFC8238] 第 6.1.1 节中定义。

- DUT 的所有端口都必须用于此测试。

- 建议同时测试所有端口。

4.2、 方法

流量发生器必须连接到 DUT 上的所有端口。为了引起拥塞，两个或多个入口端口必须发送发往同一个出口端口的数据包突发。最简单的设置是两个入口端口和一个出口端口（2 对 1）。

突发必须以 100% 的强度（如 [RFC8238]，第 6.1.1 节中定义）发送，这意味着将以最小的包间间隙发送数据包的突发。突发中包含的数据包数量将是试验变量并增加，直到测量到非零数据包丢失。来自所有发送者的数据包总量将用于计算 DUT 可以承受的最大微突发量。

建议在多次测试中改变入口和出口端口，以测量最大微突发容量。

可以改变微突发的强度（参见 [RFC8238]，第 6.1.1 节）以获得不同进入速率下的微突发容量。

建议在各种配置下同时测试 DUT 上的所有端口，以便了解入口端口、出口端口和强度的所有组合。

一个例子是：

*第一次迭代：N-1 个入口端口发送到一个出口端口。

*第二次迭代：N-2 个入口端口发送到两个出口端口。

*最后一次迭代：2个入口端口发送到 N-2 个出口端口。

4.3、 报告格式

报告必须包括以下内容：

- 每个入口端口接收到的最大数据包数，最大突发大小在零数据包丢失的情况下获得。

- 测试中使用的数据包大小。

- 入口和出口端口的数量，以及它们在 DUT 上的位置。

- 需要说明测试的可重复性：同一测试的迭代次数和结果之间变化的百分比（最小值、最大值、平均值）。

5、 队头阻塞

5.1、 目标

队头阻塞 (Head-of-line blocking，HOLB) 是一种性能限制现象，当数据包被前面等待传输到不同输出端口的第一个数据包阻止时，就会发生这种现象。这在 RFC 2889 第 5.5 节（“拥塞控制”）中定义。本节在数据中心基准测试的背景下扩展了 RFC 2889。

此测试的目的是了解 DUT 在 HOLB 场景中的行为并测量数据包丢失。

此 HOLB 测试与 RFC 2889 的区别如下：

- 此 HOLB 测试从两组中的八个端口开始，每组四个端口，而不是四个端口（与 RFC 2889 的第 5.5 节相比）。

- 此 HOLB 测试在测试的第二次迭代中将所有端口号移动 1；与 RFC 2889 中描述的 HOLB 测试相比，这是不同的。不断变化的端口号，直到所有端口成为组中的第一个；这样做的目的是确保对所有排列进行测试，以涵盖 DUT SoC 中的行为差异。

- 此 HOLB 测试中的另一项测试扩展了端口组，以便将流量分配到四个端口而不是两个端口（每个端口 25% 而不是 50%）。

- 第 5.3 节列出的要求补充 RFC 2889 第 5.5 节中列出的要求。

5.2、 方法

为了以HOLB的形式引起拥塞，使用了四个端口的组。一个组有两个入口端口和两个出口端口。第一个入口端口必须配置两个流，每个流都流向不同的出口端口。第二个入口端口将通过发送线速来阻塞第二个出口端口。目标是测量第一个出口端口的流量是否有损失，该端口没有超额订阅。

流量发生器必须连接到 DUT 上的至少八个端口，并且应该使用所有 DUT 端口进行连接。

请注意，本节中过程 1) 和 2) 中描述的测试具有称为“第一次迭代”、“第二次迭代”和“最后一次迭代”的迭代。这个想法是展示前两次迭代，以便读者理解如何不断增加迭代的逻辑。最后一次迭代显示了变量的结束状态。

1) 用八个 DUT 端口测量两组。

*第一次迭代：测量具有连续端口的两组的丢包率。

第一组的组成如下：

入口端口 1 向出口端口 3 发送 50% 的流量，入口端口 1 向出口端口 4 发送 50% 的流量。入口端口 2 向出口端口 4 发送线速。测量来自入口端口 1 到出口端口 3的流量的流量丢失量。

第二组的组成如下：

入口端口 5 向出口端口 7 发送 50% 的流量，入口端口 5 向出口端口 8 发送 50% 的流量。入口端口 6 向出口端口 8 发送线速。测量来自入口端口 5 到出口端口 7的流量的流量损失量。

*第二次迭代：通过将所有端口从 N 移动到 N+1 来重复第一次迭代。

第一组的组成如下：

入口端口 2 向出口端口 4 发送 50% 的流量，入口端口 2 向出口端口 5 发送 50% 的流量。入口端口 3 向出口端口 5 发送线速。测量来自入口端口 2 到出口端口 4的流量的流量丢失量。

第二组的组成如下：

入口端口 6 向出口端口 8 发送 50% 的流量，入口端口 6 向出口端口 9 发送 50% 的流量。入口端口 7 向出口端口 9 发送线速。测量来自入口端口 6 到出口端口 8的流量的流量损失量。

*最后一次迭代：当第一组的第一个端口连接到最后一个 DUT 端口，第二组的最后一个端口连接到 DUT 的第七个端口。

测量从入口端口 N 到出口端口 2 和从入口端口 4 到出口端口 6 的流量的流量丢失量。

2) 使用 N/4 组和 N 个 DUT 端口进行测量。

来自入口端口的流量被分成四个出口端口 (100/4 = 25%)。

*第一次迭代：扩展以充分利用所有 DUT 端口，增量为 4。对设备上可能实现的所有端口组重复过程 1) 的方法，并测量每个端口组的流量丢失量。

*第二次迭代：将端口组的每个连续端口的起点移动 +1。

*最后一次迭代：将端口组的每个连续端口的起点移动N-1，并测量每个端口组的流量丢失量。

5.3、 报告格式

对于每个测试，报告必须包括以下内容：

- 端口配置，包括位于 DUT 上的入口和出口端口的数量和位置。

- 如果按照第 5 节所述的 HOLB 测试观察到 HOLB。

- 流量损失百分比。

- 需要说明测试的可重复性：同一测试的迭代次数和结果之间变化的百分比（最小值、最大值、平均值）。

6、 Incast 有状态和无状态流量

6.1、 目标

该测试的目的是测量 TCP Goodput [TCP-INCAST] 的值和混合大小流的延迟。该测试旨在模拟需要高吞吐量的有状态流和需要低延迟的无状态流的混合环境。有状态流是通过生成 TCP 流量创建的，无状态流是使用 UDP 流量创建的。

6.2、 方法

为了模拟无状态和有状态流量对 DUT 的影响，必须有多个入口端口接收发往同一出口端口的流量。也可能混合有状态和无状态的流量到达单个入口端口。最简单的设置是两个入口端口接收发往同一个出口端口的流量。

一个入口端口必须通过入口端口与连接到出口端口的接收器保持 TCP 连接。TCP 流中的流量必须以流量生成器允许的最大速率发送。同时，TCP 流量流经 DUT，无状态流量被发送到同一出口端口上的接收器。无状态流量必须是 100% 强度的微突发。

建议在多次测试中改变入口和出口端口，以测量最大微突发容量。

可以改变微突发的强度以获得在不同进入速率下的微突发容量。

      建议在测试中使用 DUT 上的所有端口。

下面描述的测试具有称为“第一次迭代”、“第二次迭代”和“最后一次迭代”的迭代。这个想法是展示前两次迭代，以便读者理解如何不断增加迭代的逻辑。最后一次迭代显示了变量的结束状态。

例如：

有状态的流量端口变化（TCP 流量）：

需要为此测试生成 TCP 流量。在迭代期间，出口端口的数量也可能发生变化。

*第一次迭代：一个入口端口接收有状态的 TCP 流量，一个入口端口接收发往一个出口端口的无状态流量。

*第二次迭代：两个入口端口接收有状态 TCP 流量，一个入口端口接收发往一个出口端口的无状态流量。

*最后一次迭代：N-2 个入口端口接收有状态 TCP 流量，一个入口端口接收发往一个出口端口的无状态流量。

无状态流量端口变化（UDP 流量）：

需要为此测试生成 UDP 流量。在迭代期间，出口端口的数量也可能发生变化。

*第一次迭代：一个入口端口接收有状态的 TCP 流量，一个入口端口接收发往一个出口端口的无状态流量。

*第二次迭代：一个入口端口接收有状态 TCP 流量，两个入口端口接收发往一个出口端口的无状态流量。

*最后一次迭代：一个入口端口接收有状态 TCP 流量，N-2 个入口端口接收发往一个出口端口的无状态流量。

6.3、 报告格式

报告必须包括以下内容：

- 入口和出口端口的数量，以及有状态或无状态流分配的指定。

- 有状态的流量吞吐量。

- 无状态流延迟。

- 需要说明测试的可重复性：同一测试的迭代次数和结果之间变化的百分比（最小值、最大值、平均值）。

7、 安全考虑

本备忘录中描述的基准测试活动仅限于在实验室环境中使用受控刺激进行技术表征，具有专用地址空间和上述部分中指定的约束。

基准网络拓扑将是一个独立的测试设置，不得连接到可能将测试流量转发到生产网络或将流量错误路由到测试管理网络的设备。

此外，基准测试是在“黑盒”基础上执行的，仅依赖于 DUT 外部可观察到的测量值。

DUT 中不应存在专门用于基准测试的特殊功能。DUT 对网络安全的任何影响在实验室和生产网络中应该是相同的。

8、 IANA 考虑事项

本文档不需要任何 IANA 操作。

9、 参考文献

9.1、 规范性参考

[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <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>.
[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>.
[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>.
[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>.

9.2、 参考资料

[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, DOI 10.17487/RFC2432, October 1998, <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>.
[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>.
[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>.
[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>.

致谢

作者要感谢 Al Morton 和 Scott Bradner 的评论和反馈。