[要約] RFC 9004は、バックツーバックフレームベンチマークの更新に関する文書です。この文書の目的は、ネットワーク機器の性能評価基準を改善することにあります。利用場面としては、ネットワーク機器の最大負荷能力を測定し、比較する際に参照されます。
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 9004 AT&T Labs
Updates: 2544 May 2021
Category: Informational
ISSN: 2070-1721
Updates for the Back-to-Back Frame Benchmark in RFC 2544
RFCのバックツーバックフレームベンチマークの更新2544
Abstract
概要
Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience.
IETFに対する関心のあるネットワーク相互接続装置のための基本的なベンチマーク方法は、RFC 2544で定義されている。このメモは、さらなる経験に基づいて、RFC 2544のバックツーバックフレームベンチマークを測定するためのテストの手順を更新する。
This memo updates Section 26.4 of RFC 2544.
このメモ更新はRFC 2544のセクション26.4を更新します。
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 candidates 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 https://www.rfc-editor.org/info/rfc9004.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9004で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. Scope and Goals
4. Motivation
5. Prerequisites
6. Back-to-Back Frames
6.1. Preparing the List of Frame Sizes
6.2. Test for a Single Frame Size
6.3. Test Repetition and Benchmark
6.4. Benchmark Calculations
7. Reporting
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Author's Address
The IETF's fundamental benchmarking methodologies are defined in [RFC2544], supported by the terms and definitions in [RFC1242]. [RFC2544] actually obsoletes an earlier specification, [RFC1944]. Over time, the benchmarking community has updated [RFC2544] several times, including the Device Reset benchmark [RFC6201] and the important Applicability Statement [RFC6815] concerning use outside the Isolated Test Environment (ITE) required for accurate benchmarking. Other specifications implicitly update [RFC2544], such as the IPv6 benchmarking methodologies in [RFC5180].
IETFの基本的なベンチマーク方法論は[RFC2544]で定義されており、[RFC1242]の用語と定義によってサポートされています。[RFC2544]実際には以前の仕様を廃止してください[RFC1944]。時間の経過とともに、ベンチマークコミュニティは、デバイスリセットベンチマーク[RFC6201]を含む[RFC2544]と、正確なベンチマークに必要な絶縁型テスト環境（ITE）の外部の使用に関する重要な適用ステートメント[RFC6815]を含む。その他の仕様は[RFC5180]のIPv6ベンチマーク方法論などの[RFC2544]を暗黙的に更新します。
Recent testing experience with the Back-to-Back Frame test and benchmark in Section 26.4 of [RFC2544] indicates that an update is warranted [OPNFV-2017] [VSPERF-b2b]. In particular, analysis of the results indicates that buffer size matters when compensating for interruptions of software-packet processing, and this finding increases the importance of the Back-to-Back Frame characterization described here. This memo provides additional rationale and the updated method.
[RFC2544]の26.4項のバック - バックフレームテストとベンチマークの最近のテスト経験は、更新が保証されていることを示しています[OPNFV-2017] [VSPERF-B2B]。特に、結果の分析は、ソフトウェアパケット処理の中断を補償するときにバッファサイズが重要であり、この発見はここで説明されているバックツーバックフレームの特性評価の重要性を高めることを示している。このメモは追加の根拠と更新された方法を提供します。
[RFC2544] provides its own requirements language consistent with [RFC2119], since [RFC1944] (which it obsoletes) predates [RFC2119]. All three memos share common authorship. Today, [RFC8174] clarifies the usage of requirements language, so the requirements language presented in this memo are expressed in accordance with [RFC8174]. They are intended for those performing/reporting laboratory tests to improve clarity and repeatability, and for those designing devices that facilitate these tests.
[RFC2544] [RFC2119]（RFC2119]（廃止されている）Predataes [RFC2119]から、[RFC2119]と一致する独自の要件言語を提供します。3つのメモ全員が一般的な作家を共有しています。今日、[RFC8174]は要件言語の使用法を明確にします。したがって、このメモに提示されている要件言語は[RFC8174]に従って表現されます。それらは、明快さと再現性を向上させるための演奏/報告テスト、およびこれらのテストを容易にするデバイスを設計するためのものを対象としています。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The scope of this memo is to define an updated method to unambiguously perform tests, measure the benchmark(s), and report the results for Back-to-Back Frames (as described in Section 26.4 of [RFC2544]).
このメモの範囲は、テストを明確に実行し、ベンチマークを測定するための更新されたメソッドを定義し、[RFC2544]のセクション26.4で説明されているように）を参照してください。
The goal is to provide more efficient test procedures where possible and expand reporting with additional interpretation of the results. The tests described in this memo address the cases in which the maximum frame rate of a single ingress port cannot be transferred to an egress port without loss (for some frame sizes of interest).
目標は、可能な限り効率的なテスト手順を提供し、結果の追加の解釈による報告を展開することです。このメモに記載されているテストは、単一の入力ポートの最大フレームレートを損失なしに（一部のフレームサイズのために）出力ポートに転送できない場合を参照してください。
Benchmarks as described in [RFC2544] rely on test conditions with constant frame sizes, with the goal of understanding what network-device capability has been tested. Tests with the smallest size stress the header-processing capacity, and tests with the largest size stress the overall bit-processing capacity. Tests with sizes in between may determine the transition between these two capacities. However, conditions simultaneously sending a mixture of Internet (IMIX) frame sizes, such as those described in [RFC6985], MUST NOT be used in Back-to-Back Frame testing.
[RFC2544]で説明されているベンチマークは、どのネットワークデバイス機能がテストされているかを理解することを目的として、一定のフレームサイズを持つテスト条件に依存しています。最小のサイズのストレスを持つテストヘッダー処理能力、および最大サイズのストレスを持つテストは、全体のビット処理能力を強調します。間のサイズを持つテストは、これら2つの容量の間の遷移を決定するかもしれません。ただし、[RFC6985]に記載されているようなインターネット（IMIX）フレームサイズの混在を同時に送信する条件は、バックツーバックフレームテストでは使用してはいけません。
Section 3 of [RFC8239] describes buffer-size testing for physical networking devices in a data center. Those methods measure buffer latency directly with traffic on multiple ingress ports that overload an egress port on the Device Under Test (DUT) and are not subject to the revised calculations presented in this memo. Likewise, the methods of [RFC8239] SHOULD be used for test cases where the egress-port buffer is the known point of overload.
[RFC8239]のセクション3は、データセンターの物理ネットワークデバイスのバッファサイズテストを表しています。これらのメソッドは、テスト中のデバイス上のデバイス上の出力ポートをオーバーロードする複数の入力ポート上のトラフィックと直接バッファの待ち時間を測定し、このメモに提示された改訂された計算の対象とはなりません。同様に、[RFC8239]の方法は、出力ポートバッファが既知の過負荷点であるテストケースに使用する必要があります。
Section 3.1 of [RFC1242] describes the rationale for the Back-to-Back Frames benchmark. To summarize, there are several reasons that devices on a network produce bursts of frames at the minimum allowed spacing; and it is, therefore, worthwhile to understand the DUT limit on the length of such bursts in practice. The same document also states:
[RFC1242]のセクション3.1は、バックツーバックフレームベンチマークの根拠を説明しています。要約すると、ネットワーク上のデバイスが最小許容間隔でフレームのバーストを生成するいくつかの理由があります。それゆえ、それは実際にはそのようなバーストの長さにDUTの限界を理解することを理解することです。同じ文書も次のとおりです。
| Tests of this parameter are intended to determine the extent of | data buffering in the device.
| ..このパラメータのテストは|の範囲を決定するためのものです。デバイス内のデータバッファリング
Since this test was defined, there have been occasional discussions of the stability and repeatability of the results, both over time and across labs. Fortunately, the Open Platform for Network Function Virtualization (OPNFV) project on Virtual Switch Performance (VSPERF) Continuous Integration (CI) [VSPERF-CI] testing routinely repeats Back-to-Back Frame tests to verify that test functionality has been maintained through development of the test-control programs. These tests were used as a basis to evaluate stability and repeatability, even across lab setups when the test platform was migrated to new DUT hardware at the end of 2016.
この試験は定義されているので、経時的な結果の安定性と再現性についての時折議論がありました。幸い、ネットワーク機能仮想化のためのオープンプラットフォーム（opnfv）仮想スイッチパフォーマンス（vsperf）継続統合（CI）[VSPERF-CI]テストでは、テスト機能が開発を通じて維持されていることを確認するためにバックツーバックフレームテストを繰り返します。テスト制御プログラムの。これらのテストは、テストプラットフォームが2016年末に新しいDUTハードウェアに移行されたときでさえ、実験室の設定を介しても、安定性と再現性を評価するための基礎として使用されました。
When the VSPERF CI results were examined [VSPERF-b2b], several aspects of the results were considered notable:
VSPERF CIが検討された[VSPERF-B2B]を調べたと、結果のいくつかの側面が注目に値すると考えられていました。
1. Back-to-Back Frame benchmark was very consistent for some fixed frame sizes, and somewhat variable for other frame sizes.
1. バックツーバックフレームベンチマークは、いくつかの固定フレームサイズ、および他のフレームサイズに対してやや変数に非常に矛盾していました。
2. The number of Back-to-Back Frames with zero loss reported for large frame sizes was unexpectedly long (translating to 30 seconds of buffer time), and no explanation or measurement limit condition was indicated. It was important that the buffering time calculations were part of the referenced testing and analysis [VSPERF-b2b], because the calculated buffer time of 30 seconds for some frame sizes was clearly wrong or highly suspect. On the other hand, a result expressed only as a large number of Back-to-Back Frames does not permit such an easy comparison with reality.
2. 大きなフレームサイズに対して報告されたゼロ損失を有するバックツーバックフレームの数は予期せず（30秒のバッファ時間に並ぶ）、説明または測定制限条件は示されなかった。いくつかのフレームサイズについての計算されたバッファ時間は明らかに間違っているか疑わしいので、バッファリング時間計算は参照されたテストおよび分析の一部であることが重要でした。一方、バックツーバックフレームの多数としてのみ表現された結果は、現実とのような容易な比較を許可しない。
3. Calculation of the extent of buffer time in the DUT helped to explain the results observed with all frame sizes. For example, tests with some frame sizes cannot exceed the frame-header-processing rate of the DUT, thus, no buffering occurs. Therefore, the results depended on the test equipment and not the DUT.
3. DUTにおけるバッファ時間の範囲の計算は、すべてのフレームサイズで観察された結果を説明するのに役立ちました。例えば、いくつかのフレームサイズを有するテストは、DUTのフレームヘッダ処理率を超えることができないため、バッファリングは発生しない。したがって、結果は試験装置に依存しており、DUTではなく依存していました。
4. It was found that a better estimate of the DUT buffer time could be calculated using measurements of both the longest burst in frames without loss and results from the Throughput tests conducted according to Section 26.1 of [RFC2544]. It is apparent that the DUT's frame-processing rate empties the buffer during a trial and tends to increase the "implied" buffer-size estimate (measured according to Section 26.4 of [RFC2544] because many frames have departed the buffer when the burst of frames ends). A calculation using the Throughput measurement can reveal a "corrected" buffer-size estimate.
4. DUTバッファ時間のより良い推定値は、損失なしで最も長いバーストの測定値を使用して計算することができ、[RFC2544]のセクション26.1に従って行われたスループットテストからの結果をもたらすことがわかった。試験中にDUTのフレーム処理レートがバッファを空にすると明らかであり、フレームのバーストのときに多くのフレームがバッファを逸脱したため、[RFC2544のセクション26.4に従って測定された]を増やす傾向がある。終わる。スループット測定を用いた計算により、「補正された」バッファサイズの推定値が明らかになる。
Further, if the Throughput tests of Section 26.1 of [RFC2544] are conducted as a prerequisite, the number of frame sizes required for Back-to-Back Frame benchmarking can be reduced to one or more of the small frame sizes, or the results for large frame sizes can be noted as invalid in the results if tested anyway. These are the larger frame sizes for which the Back-to-Back Frame rate cannot exceed the frame-header-processing rate of the DUT and little or no buffering occurs.
また、[RFC2544]のセクション26.1のスループットテストが前提条件として行われている場合、バックボックスフレームベンチマークに必要なフレームサイズの数を1つ以上の小フレームサイズの1つ以上にすることもできます。とにかくテストされている場合、結果の大きなフレームサイズは結果の無効として認められます。これらは、バックツーバックフレームレートがDUTのフレームヘッダ処理率を超えることができず、バッファリングがほとんど発生しない、フレームサイズが大きくなる。
The material below provides the details of the calculation to estimate the actual buffer storage available in the DUT, using results from the Throughput tests for each frame size and the Max Theoretical Frame Rate for the DUT links (which constrain the minimum frame spacing).
以下の材料は、各フレームサイズについてのスループット試験からの結果を使用して、DUTで使用可能な実際のバッファストレージを推定するための計算の詳細を提供し、DUTリンク（最小フレーム間隔を制限する）の最大理論フレームレートからの結果を提供します。
In reality, there are many buffers and packet-header-processing steps in a typical DUT. The simplified model used in these calculations for the DUT includes a packet-header-processing function with limited rate of operation, as shown in Figure 1.
実際には、典型的なDUTには多くのバッファとパケットヘッダ処理ステップがあります。これらのDUTの計算で使用される簡易モデルは、図1に示すように、制限された動作速度を有するパケットヘッダ処理機能を含む。
|------------ DUT --------|
Generator -> Ingress -> Buffer -> HeaderProc -> Egress -> Receiver
Figure 1: Simplified Model for DUT Testing
図1：DUTテストのための簡易モデル
So, in the Back-to-Back Frame testing:
そのため、バックツーバックフレームテストでは、次の手順を実行します。
1. The ingress burst arrives at Max Theoretical Frame Rate, and initially the frames are buffered.
1. 入力バーストは最大理論的フレームレートに到着し、最初はフレームがバッファされます。
2. The packet-header-processing function (HeaderProc) operates at the "Measured Throughput" (Section 26.1 of [RFC2544]), removing frames from the buffer (this is the best approximation we have, another acceptable approximation is the received frame rate during Back-to-back Frame testing, if Measured Throughput is not available).
2. パケットヘッダ処理機能（ヘッダプロセス）は、「測定されたスループット」（[RFC2544]のセクション26.1）で動作し、バッファからフレームを削除します（これは私たちが持っている最良の近似値です、別の許容可能な近似は後の受信フレームレートです。測定されたスループットが利用できない場合、バックフレームテスト。
3. Frames that have been processed are clearly not in the buffer, so the Corrected DUT Buffer Time equation (Section 6.4) estimates and removes the frames that the DUT forwarded on egress during the burst. We define buffer time as the number of frames occupying the buffer divided by the Max Theoretical Frame Rate (on ingress) for the frame size under test.
3. 処理されたフレームは明らかにバッファ内ではないので、修正されたDULバッファ時間式（セクション6.4）は、バースト中にDUTが出力に転送されたフレームを除去して削除する。バッファを占めるフレーム数としてバッファを占めるフレームの数が、テスト中のフレームサイズのマックス理論フレームレート（入力）で割ったものとして定義します。
4. A helpful concept is the buffer-filling rate, which is the difference between the Max Theoretical Frame Rate (ingress) and the Measured Throughput (HeaderProc on egress). If the actual buffer size in frames is known, the time to fill the buffer during a measurement can be calculated using the filling rate, as a check on measurements. However, the buffer in the model represents many buffers of different sizes in the DUT data path.
4. 役に立つ概念はバッファー充填率です。これは、最大理論フレームレート（入力）と測定されたスループット（EGRESSのヘッダープロークト）の差です。フレーム内の実際のバッファサイズが既知である場合、測定中にバッファを埋める時間は、充填率を使用して、測定値の測定として計算できます。ただし、モデル内のバッファは、DUTデータパス内の異なるサイズの多くのバッファを表します。
Knowledge of approximate buffer storage size (in time or bytes) may be useful in estimating whether frame losses will occur if DUT forwarding is temporarily suspended in a production deployment due to an unexpected interruption of frame processing (an interruption of duration greater than the estimated buffer would certainly cause lost frames). In Section 6, the calculations for the correct buffer time use the combination of offered load at Max Theoretical Frame Rate and header-processing speed at 100% of Measured Throughput. Other combinations are possible, such as changing the percent of Measured Throughput to account for other processes reducing the header processing rate.
近似バッファ記憶サイズの知識（時間またはバイト）は、フレーム処理の予期しない中断（推定バッファよりも大きい持続時間の中断）を一時的に製造展開で一時的に中断される場合には、フレーム損失が発生するかどうかを推定することができる。確かに失われたフレームを引き起こすでしょう）。第6章では、正しいバッファ時間の計算は、測定されたスループットの100％での最大理論フレームレートとヘッダー処理速度での提供された負荷の組み合わせを使用します。ヘッダ処理率を下げる他のプロセスを考慮して、測定されたスループットのパーセントを変更するなど、他の組み合わせが可能である。
The presentation of OPNFV VSPERF evaluation and development of enhanced search algorithms [VSPERF-BSLV] was given and discussed at IETF 102. The enhancements are intended to compensate for transient processor interrupts that may cause loss at near-Throughput levels of offered load. Subsequent analysis of the results indicates that buffers within the DUT can compensate for some interrupts, and this finding increases the importance of the Back-to-Back Frame characterization described here.
OPNFV VSPERFの評価と強化された検索アルゴリズムの開発[VSPERF-BSLV]の開発を、IETF 102で説明し説明した。機能強化は、提供された負荷の近くのスループットレベルで損失を引き起こす可能性がある一時的なプロセッサ割り込みを補償することを目的としています。結果の後続の分析は、DUT内のバッファがいくつかの割り込みを補償することができ、この発見はここで説明されているバックツーバックフレームの特性評価の重要性を高めることを示しています。
The test setup MUST be consistent with Figure 1 of [RFC2544], or Figure 2 of that document when the tester's sender and receiver are different devices. Other mandatory testing aspects described in [RFC2544] MUST be included, unless explicitly modified in the next section.
テストセットアップは、[RFC2544]の図1、またはテスターの送信者と受信機が異なるデバイスである場合のその文書の図2と一致している必要があります。次のセクションで明示的に変更されない限り、[RFC2544]に記載されている他の必須テストの側面を含める必要があります。
The ingress and egress link speeds and link-layer protocols MUST be specified and used to compute the Max Theoretical Frame Rate when respecting the minimum interframe gap.
最小フレーム間ギャップを尊重するときの最大理論フレームレートを計算するためには、入力と出力のリンク速度とリンク層プロトコルを指定して使用する必要があります。
The test results for the Throughput benchmark conducted according to Section 26.1 of [RFC2544] for all frame sizes RECOMMENDED by [RFC2544] MUST be available to reduce the tested-frame-size list or to note invalid results for individual frame sizes (because the burst length may be essentially infinite for large frame sizes).
[RFC2544]で推奨されるすべてのフレームサイズについて[RFC2544]のセクション26.1に従って実施されたスループットベンチマークのテスト結果は、テスト済みフレームサイズリストを縮小するため、または個々のフレームサイズの無効な結果を注意する必要があります（バースト長さは大きなフレームサイズのために本質的に無限かもしれません。
Note that:
ご了承ください：
* the Throughput and the Back-to-Back Frame measurement-configuration traffic characteristics (unidirectional or bidirectional, and number of flows generated) MUST match.
* スループットとバックツーバックフレーム測定コンフィギュレーショントラフィック特性（一方向または双方向、生成されたフロー数）が一致する必要があります。
* the Throughput measurement MUST be taken under zero-loss conditions, according to Section 26.1 of [RFC2544].
* [RFC2544]のセクション26.1によると、スループット測定はゼロロス条件下で行わなければなりません。
The Back-to-Back Benchmark described in Section 3.1 of [RFC1242] MUST be measured directly by the tester, where buffer size is inferred from Back-to-Back Frame bursts and associated packet-loss measurements. Therefore, sources of frame loss that are unrelated to consistent evaluation of buffer size SHOULD be identified and removed or mitigated. Example sources include:
[RFC1242]のセクション3.1に記載されているバックツーバックベンチマークは、バックサイズがバックツーバックフレームバーストと関連するパケット損失測定から推測されているテスターによって直接測定されなければなりません。したがって、バッファサイズの一貫した評価とは無関係のフレーム損失の原因は、識別および削除または軽減されるべきである。サンプルソースの例は次のとおりです。
* On-path active components that are external to the DUT
* DUTの外部にあるオンパスアクティブコンポーネント
* Operating-system environment interrupting DUT operation
* オペレーティングシステム環境を中断しています
* Shared-resource contention between the DUT and other off-path component(s) impacting DUT's behavior, sometimes called the "noisy neighbor" problem with virtualized network functions.
* DUTの行動に影響を与えるDUTの行動と他のオフパスコンポーネント間の共有リソース競合は、仮想化ネットワーク機能に関する「ノイズのある隣人」の問題と呼ばれることがあります。
Mitigations applicable to some of the sources above are discussed in Section 6.2, with the other measurement requirements described below in Section 6.
上記の要因のいくつかに適用可能な軽減は、セクション6.2で議論されており、その他の測定要件は6節で説明されています。
Objective: To characterize the ability of a DUT to process Back-to-Back Frames as defined in [RFC1242].
目的：[RFC1242]で定義されているとおりにバック間フレームを処理するためのDUTの能力を特徴付けること。
The procedure follows.
手順は続きます。
From the list of RECOMMENDED frame sizes (Section 9 of [RFC2544]), select the subset of frame sizes whose Measured Throughput (during prerequisite testing) was less than the Max Theoretical Frame Rate of the DUT/test setup. These are the only frame sizes where it is possible to produce a burst of frames that cause the DUT buffers to fill and eventually overflow, producing one or more discarded frames.
推奨されるフレームサイズのリストから（[RFC2544]のセクション9）、測定されたスループット（前提条件テスト中）がDUT / TEST設定の最大理論フレームレートよりも小さいフレームサイズのサブセットを選択します。これらは唯一のフレームサイズであり、DUTバッファを充填し、最終的にオーバーフローさせ、1つまたは複数の廃棄されたフレームを生成するフレームのバーストを生成することが可能である。
Each trial in the test requires the tester to send a burst of frames (after idle time) with the minimum interframe gap and to count the corresponding frames forwarded by the DUT.
テストにおける各試行は、テスタが最小のフレーム間ギャップで（アイドル時間後）フレームのバースト（アイドル時間後）を送信し、DUTによって転送された対応するフレームをカウントすることを要求する。
The duration of the trial includes three REQUIRED components:
試験期間には3つの必要な部品が含まれています。
1. The time to send the burst of frames (at the back-to-back rate), determined by the search algorithm.
1. 検索アルゴリズムによって決定された、フレームのバースト（バック - バックレート）を送信する時間。
2. The time to receive the transferred burst of frames (at the [RFC2544] Throughput rate), possibly truncated by buffer overflow, and certainly including the latency of the DUT.
2. 転送されたフレームのバーストを受信する時間（[RFC2544]スループットレート）は、バッファオーバーフローによって切り捨てられ、確かにDUTの待ち時間を含む。
3. At least 2 seconds not overlapping the time to receive the burst (Component 2, above), to ensure that DUT buffers have depleted. Longer times MUST be used when conditions warrant, such as when buffer times >2 seconds are measured or when burst sending times are >2 seconds, but care is needed, since this time component directly increases trial duration, and many trials and tests comprise a complete benchmarking study.
3. DUTバッファが枯渇していることを確認するために、バースト（コンポーネント2、上記の）を受信する時間と重ならない少なくとも2秒。バッファタイムが測定されたとき、またはバースト送信時間が2秒かかるときなど、条件の保証が必要な場合は、より長い時間を使用する必要がありますが、この時間成分はトライアル期間を直接増加させるため、完全なベンチマーク研究
The upper search limit for the time to send each burst MUST be configurable to values as high as 30 seconds (buffer time results reported at or near the configured upper limit are likely invalid, and the test MUST be repeated with a higher search limit).
各バーストを送信する時間の上限検索制限は、30秒程度の値に設定可能でなければなりません（設定された上限で報告されたバッファ時間の結果は無効である可能性があり、テストをより高い検索制限で繰り返す必要があります）。
If all frames have been received, the tester increases the length of the burst according to the search algorithm and performs another trial.
全てのフレームが受信された場合、テスタは検索アルゴリズムに従ってバーストの長さを増加させ、別の試行を実行する。
If the received frame count is less than the number of frames in the burst, then the limit of DUT processing and buffering may have been exceeded, and the burst length for the next trial is determined by the search algorithm (the burst length is typically reduced, but see below).
受信したフレーム数がバースト内のフレーム数より少ない場合、DUT処理およびバッファリングの制限が超えられ、次の試行のバースト長は検索アルゴリズムによって決定される（バースト長は典型的には減少する。下記参照）。
Classic search algorithms have been adapted for use in benchmarking, where the search requires discovery of a pair of outcomes, one with no loss and another with loss, at load conditions within the acceptable tolerance or accuracy. Conditions encountered when benchmarking the infrastructure for network function virtualization require algorithm enhancement. Fortunately, the adaptation of Binary Search, and an enhanced Binary Search with Loss Verification, have been specified in Clause 12.3 of [TST009]. These algorithms can easily be used for Back-to-Back Frame benchmarking by replacing the offered load level with burst length in frames. [TST009], Annex B describes the theory behind the enhanced Binary Search with Loss Verification algorithm.
古典的な検索アルゴリズムはベンチマークでの使用に適しています。そこでは、検索には、許容可能な耐性または正確さの範囲内の負荷条件で、一対の結果、損失のないもの、もう1つは損失のあるもの、もう1つの損失が必要です。ネットワーク機能仮想化のためにインフラストラクチャをベンチマークするときに発生した条件は、アルゴリズムの強化を必要とします。幸いなことに、バイナリ検索の適応、および損失検証による強化されたバイナリ検索は、[TST009]の12.3項に指定されています。これらのアルゴリズムは、オファーされた負荷レベルをフレーム内のバースト長で置き換えることによって、バックツーバックフレームベンチマークに簡単に使用できます。[TST009]、附属書Bは、損失検証アルゴリズムによる強化されたバイナリ検索の背後にある理論を表しています。
There are also promising works in progress that may prove useful in Back-to-Back Frame benchmarking. [BMWG-MLRSEARCH] and [BMWG-PLRSEARCH] are two such examples.
バックツーバックフレームベンチマークで有用であることが証明される可能性がある進歩にも有望な作品もあります。[BMWG-MLRSEARCH]および[BMWG-PLRSEARCH]は、そのような例2である。
Either the [TST009] Binary Search or Binary Search with Loss Verification algorithms MUST be used, and input parameters to the algorithm(s) MUST be reported.
損失検証アルゴリズムを使用した[TST009]バイナリ検索またはバイナリ検索を使用する必要があり、アルゴリズムへの入力パラメータを報告する必要があります。
The tester usually imposes a (configurable) minimum step size for burst length, and the step size MUST be reported with the results (as this influences the accuracy and variation of test results).
テスターは通常、バースト長の（設定可能）最小ステップサイズを課し、ステップサイズは結果と報告されなければなりません（これがテスト結果の正確さと変化に影響を与えるため）。
The original Section 26.4 of [RFC2544] definition is stated below:
[RFC2544]の定義の元のセクション26.4は以下のとおりです。
| The back-to-back value is the number of frames in the longest | burst that the DUT will handle without the loss of any frames.
| ..バックツーバック値は、最長のフレーム数です。DUTがフレームの損失なしに扱うことになるようにバーストします。
On this topic, Section 26.4 of [RFC2544] requires:
このトピックでは、[RFC2544]のセクション26.4が必要です。
| The trial length MUST be at least 2 seconds and SHOULD be repeated
| at least 50 times with the average of the recorded values being
| reported.
Therefore, the Back-to-Back Frame benchmark is the average of burst-length values over repeated tests to determine the longest burst of frames that the DUT can successfully process and buffer without frame loss. Each of the repeated tests completes an independent search process.
したがって、バックツーバックフレームベンチマークは、DUTが正常に処理され、フレーム損失なしで緩衝できるフレームの最も長いバーストを決定するために、繰り返しテストにわたるバースト長の値の平均です。繰り返しテストのそれぞれは、独立した検索プロセスを完了します。
In this update, the test MUST be repeated N times (the number of repetitions is now a variable that must be reported) for each frame size in the subset list, and each Back-to-Back Frame value MUST be made available for further processing (below).
このアップデートでは、サブセットリスト内の各フレームサイズに対して、テストをN回繰り返す必要があります（繰り返し回数は報告されなければならない変数になりました）、各バックツーバックフレーム値はさらなる処理のために利用可能にする必要があります。（未満）。
For each frame size, calculate the following summary statistics for longest Back-to-Back Frame values over the N tests:
各フレームサイズについて、Nテストで最長のバックツーバックフレーム値について次の要約統計を計算します。
* Average (Benchmark)
* 平均（ベンチマーク）
* Minimum
* 最小
* Maximum
* 最大
* Standard Deviation
* 標準偏差
Further, calculate the Implied DUT Buffer Time and the Corrected DUT Buffer Time in seconds, as follows:
さらに、暗黙のDUTバッファ時間と補正DUTバッファ時間を秒単位で計算します。
Implied DUT buffer time =
暗黙のDUTバッファ時間=
Average num of Back-to-back Frames / Max Theoretical Frame Rate
バックツーバックフレーム/最大理論フレームレートの平均数
The formula above is simply expressing the burst of frames in units of time.
上記の式は単に時間単位でフレームのバーストを表現しています。
The next step is to apply a correction factor that accounts for the DUT's frame forwarding operation during the test (assuming the simple model of the DUT composed of a buffer and a forwarding function, described in Section 4).
次のステップは、テスト中のDUTのフレーム転送操作を説明する補正係数を適用します（セクション4で説明したバッファと転送機能とからなる転送関数とを想定して）。
Corrected DUT Buffer Time =
/ \
Implied DUT |Implied DUT Measured Throughput |
= Buffer Time - |Buffer Time * -------------------------- |
| Max Theoretical Frame Rate |
\ /
where:
ただし：
1. The "Measured Throughput" is the [RFC2544] Throughput Benchmark for the frame size tested, as augmented by methods including the Binary Search with Loss Verification algorithm in [TST009] where applicable and MUST be expressed in frames per second in this equation.
1. 「測定されたスループット」は、該当する場合には、この式で毎秒フレームで表現されなければならない。
2. The "Max Theoretical Frame Rate" is a calculated value for the interface speed and link-layer technology used, and it MUST be expressed in frames per second in this equation.
2. 「最大理論フレームレート」は、使用されるインターフェース速度およびリンク層技術の計算値であり、この式では1秒あたりのフレームで表現されなければならない。
The term on the far right in the formula for Corrected DUT Buffer Time accounts for all the frames in the burst that were transmitted by the DUT *while the burst of frames was sent in*. So, these frames are not in the buffer, and the buffer size is more accurately estimated by excluding them. If Measured Throughput is not available, an acceptable approximation is the received frame rate (see Forwarding Rate in [RFC2889] measured during Back-to-back Frame testing).
DUTバッファ時間の決定のための式の右上の用語は、DUT *によって送信されたバースト内のすべてのフレームを占め、フレームのバーストが*で送信されました。したがって、これらのフレームはバッファ内にはなく、バッファサイズはそれらを除外することによってより正確に推定されます。測定されたスループットが利用できない場合、許容可能な近似は受信フレームレートです（バックツーバックフレームテスト中に測定された[RFC2889]の転送速度を参照）。
The Back-to-Back Frame results SHOULD be reported in the format of a table with a row for each of the tested frame sizes. There SHOULD be columns for the frame size and the resultant average frame count for each type of data stream tested.
バックツーバックフレームの結果は、テストされた各フレームサイズごとに行を持つテーブルの形式で報告される必要があります。テストされた各タイプのデータストリームについて、フレームサイズと結果の平均フレーム数の列があるはずです。
The number of tests averaged for the benchmark, N, MUST be reported.
ベンチマーク、nの平均化されたテストの数を報告する必要があります。
The minimum, maximum, and standard deviation across all complete tests SHOULD also be reported (they are referred to as "Min,Max,StdDev" in Table 1).
全ての完全なテストにわたる最小、最大、および標準偏差も報告されるべきです（それらは、表1の「min、max、stddev」と呼ばれます）。
The Corrected DUT Buffer Time SHOULD also be reported.
修正されたDUTバッファ時間も報告する必要があります。
If the tester operates using a limited maximum burst length in frames, then this maximum length SHOULD be reported.
テスタがフレーム内の制限された最大バースト長を使用して動作する場合、この最大長は報告されるべきです。
+=============+================+================+================+
| Frame Size, | Ave B2B | Min,Max,StdDev | Corrected Buff |
| octets | Length, frames | | Time, Sec |
+=============+================+================+================+
| 64 | 26000 | 25500,27000,20 | 0.00004 |
+-------------+----------------+----------------+----------------+
Table 1: Back-to-Back Frame Results
表1：バックツーバックフレームの結果
Static and configuration parameters (reported with Table 1):
静的および構成のパラメータ（表1で報告されています）。
* Number of test repetitions, N
* テスト繰り返しの数N
* Minimum Step Size (during searches), in frames.
* フレーム内の最小ステップサイズ（検索中）。
If the tester has a specific (actual) frame rate of interest (less than the Throughput rate), it is useful to estimate the buffer time at that actual frame rate:
テスタに特定の（実際の）フレームレートが含まれている場合（スループットレートよりも小さい）、その実際のフレームレートでバッファタイムを推定するのに役立ちます。
Actual Buffer Time =
Max Theoretical Frame Rate
= Corrected DUT Buffer Time * --------------------------
Actual Frame Rate
and report this value, properly labeled.
そしてこの値を報告し、正しくラベル付けされています。
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 other constraints of [RFC2544].
このメモに記載されているベンチマーク活動は、専用のアドレス空間および[RFC2544]の他の制約を備えた、実験室環境における制御された刺激を用いた技術の特徴付けに限定されている。
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. See [RFC6815].
ベンチマークネットワークトポロジは独立したテスト設定になり、テストトラフィックをプロダクションネットワークまたはテスト管理ネットワークへの誤表示トラフィックに転送する可能性があるデバイスに接続してはなりません。[RFC6815]を参照してください。
Further, benchmarking is performed on an "opaque-box" (a.k.a. "black-box") basis, relying solely on measurements observable external to the Device or System Under Test (SUT).
さらに、ベンチマークは、「不透明ボックス」（A.K.A.Bブラックボックス）で行われ、試験中の装置またはシステム（SUT）の下で観測される測定可能な測定値のみに頼っている。
The DUT developers are commonly independent from the personnel and institutions conducting benchmarking studies. DUT developers might have incentives to alter the performance of the DUT if the test conditions can be detected. Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Procedures described in this document are not designed to detect such activity. Additional testing outside of the scope of this document would be needed and has been used successfully in the past to discover such malpractices.
DUT開発者は、ベンチマーク研究を行う人員や機関から一般的に独立しています。試験条件を検出できる場合、DUT開発者はDUTのパフォーマンスを変更するためのインセンティブを持っている可能性があります。特にベンチマーク目的で特にDUT / SUTに特別な機能が存在しないはずです。この文書に記載されている手順は、そのような活動を検出するようには設計されていません。この文書の範囲外の追加のテストは必要とされ、そのような明示的な明示的な発見には過去にうまく使用されています。
Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
DUT / SUTから生じるネットワークセキュリティへの影響は、実験室および生産ネットワークにおいて同一であるべきです。
This document has no 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、「RFCSで使用するためのキーワード」、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.Cquaid、「ネットワークインターコネクトデバイスのベンチマーク方法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<https：//www.rfc-editor.org/info/rfc2544>。
[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]モートン、A。、「IMIXゲノム：追加テストのための可変パケットサイズの指定」、RFC 6985、DOI 10.17487 / RFC6985、2013年7月、<https：//www.rfc-editor.org/info/rfc6985>。
[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>。
[RFC8239] Avramov, L. and J. Rapp, "Data Center Benchmarking Methodology", RFC 8239, DOI 10.17487/RFC8239, August 2017, <https://www.rfc-editor.org/info/rfc8239>.
[RFC8239] Avramov、L.およびJ.RAPP、「データセンターベンチマーク方法」、RFC 8239、DOI 10.17487 / RFC8239、2017年8月、<https://www.rfc-editor.org/info/rfc8239>。
[TST009] ETSI, "Network Functions Virtualisation (NFV) Release 3; Testing; Specification of Networking Benchmarks and Measurement Methods for NFVI", Rapporteur: A. Morton, ETSI GS NFV-TST 009 v3.4.1, December 2020, <https://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/009/03.04.01_60/gs_NFV-TST009v030401p.pdf>.
[TST009] ETSI、「ネットワーク機能仮想化（NFV）リリース3;テスト; NFVIのネットワーキングベンチマークと測定方法の仕様、RapPorteur：A. Morton、ETSI GS NFV-TST 009 V3.4.1、2020年12月、<https：//www.etsi.org/deliver/etsi_gs/nfv-tst/001_099/009/03.04.01_60/gs_nfv-tst009v030401p.pdf>。
[BMWG-MLRSEARCH] Konstantynowicz, M., Ed. and V. Polák, Ed., "Multiple Loss Ratio Search for Packet Throughput (MLRsearch)", Work in Progress, Internet-Draft, draft-ietf-bmwg-mlrsearch-00, 9 February 2021, <https://tools.ietf.org/html/draft-ietf-bmwg-mlrsearch-00>.
[BMWG-MLRSEARCH] KonstantyNowicz、M.、ED。V.Polák、「パケットスループット（MLRSearch）の多重損失比検索」、進行中の作業、インターネットドラフト、草案-IETF-BMWG-MLRSearch-00,9021、<https：//ツール。ietf.org/html/draft-ietf-bmwg-mlrsearch-00>。
[BMWG-PLRSEARCH] Konstantynowicz, M., Ed. and V. Polák, Ed., "Probabilistic Loss Ratio Search for Packet Throughput (PLRsearch)", Work in Progress, Internet-Draft, draft-vpolak-bmwg-plrsearch-03, 6 March 2020, <https://tools.ietf.org/html/draft-vpolak-bmwg-plrsearch-03>.
[BMWG-PLRSEARCH] Konstantynowicz、M.、ED。V.Polák、「Packilistic Ression Ratio（PlrSearch）の検索」、進行中の作業、インターネットドラフト、ドラフト - VPOLAK-BMWG-PLRSearch-03,2020、<https：//ツール。ietf.org/html/draft-vpolak-bmwg-plrsearch-03>。
[OPNFV-2017] Cooper, T., Rao, S., and A. Morton, "Dataplane Performance, Capacity, and Benchmarking in OPNFV", 15 June 2017, <https://wiki.anuket.io/download/attachments/4404001/ VSPERF-Dataplane-Perf-Cap-Bench.pdf?version=1&modification Date=1621191833500&api=v2>.
[OPNFV-2017] Cooper、T.、Rao、S、およびA.モートン、「データプレーンのパフォーマンス、能力、およびベンチマーク」2017年6月15日、<https：//wiki.anuket.io/download/attachments/ 4404001 / vsperf-dataplane-perf-cap-bench.pdf？version = 1と修正日= 1621191833500＆API = V2>。
[RFC1944] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 1944, DOI 10.17487/RFC1944, May 1996, <https://www.rfc-editor.org/info/rfc1944>.
[RFC1944] Bradner、S.およびJ.Cquaid、「ネットワークインターコネクトデバイスのベンチマーク方法」、RFC 1944、DOI 10.17487 / RFC1944、1996年5月、<https：//www.rfc-editor.org/info/rfc1944>。
[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、「LANスイッチングデバイスのベンチマーク方法」、RFC 2889、DOI 10.17487 / RFC2889、2000年8月、<https：//www.rfc-editor.org/info/rfc2889>。
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 2008, <https://www.rfc-editor.org/info/rfc5180>.
[RFC5180] Popoviciu、C.、Hamza、A。、Van de Velde、G.、およびD. Dugatkin、「ネットワークインターコネクト装置のためのIPv6ベンチマーク方法」、RFC 5180、DOI 10.17487 / RFC5180、2008年5月、<https：//www.rfc-editor.org/info/rfc5180>。
[RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, "Device Reset Characterization", RFC 6201, DOI 10.17487/RFC6201, March 2011, <https://www.rfc-editor.org/info/rfc6201>.
[RFC6201] ASATI、R.、PIGNATARO、C、CALABRIA、F、およびC. Olvera、「デバイスリセットキャラクタリゼーション」、RFC 6201、DOI 10.17487 / RFC6201、2011年3月、<https：//www.rfc-編集者.ORG / INFO / RFC6201>。
[RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, <https://www.rfc-editor.org/info/rfc6815>.
[RFC6815] Bradner、S.、Dubray、K.、McQuaid、J.、およびA.モートン、「RFC 2544の適用性声明：有害と見なされる生産ネットワークの使用」、RFC 6815、DOI 10.17487 / RFC6815、2012年11月、<https://www.rfc-editor.org/info/rfc6815>。
[VSPERF-b2b] Morton, A., "Back2Back Testing Time Series (from CI)", May 2021, <https://wiki.anuket.io/display/HOME/ Traffic+Generator+Testing#TrafficGeneratorTesting-AppendixB:Back2BackTestingTimeSeries(fromCI)>.
[VSPERF-B2B]モートン、A。、「Back2backテスト時シリーズ（CIからのテスト時シリーズ」、<https：//wiki.anuket.io/display/home/トラフィックジェネレータテスト＃TrafficGenerAtortEsting-付録B：Back2backtestingTimeseries（FromCi）>。
[VSPERF-BSLV] Rao, S. and A. Morton, "Evolution of Repeatability in Benchmarking: Fraser Plugfest (Summary for IETF BMWG)", July 2018, <https://datatracker.ietf.org/meeting/102/materials/ slides-102-bmwg-evolution-of-repeatability-in-benchmarking-fraser-plugfest-summary-for-ietf-bmwg-00>.
[VSPERF-BSLV] RAO、S.およびA.モートン、「ベンチマークにおける再現性の進化：Fraser Plugfest（IETF BMWGの要約）」、2018年7月、<https：//datatracker.ietf.org/meeting/102/Materials/スライド-22-BMWG-repeation-in-benchmarking-fraser-plugfest-summary-for-IETF-BMWG-00>。
[VSPERF-CI] Tahhan, M., "OPNFV VSPERF CI", September 2019, <https://wiki.anuket.io/display/HOME/VSPERF+CI>.
[VSPERF-CI] Tahhan、M.、「OpnFv VSPERF CI」、2019年9月、<https：//wiki.anuket.io/display/home/vsperf ci>。
Acknowledgments
謝辞
Thanks to Trevor Cooper, Sridhar Rao, and Martin Klozik of the VSPERF project for many contributions to the early testing [VSPERF-b2b]. Yoshiaki Itou has also investigated the topic and made useful suggestions. Maciek Konstantyowicz and Vratko Polák also provided many comments and suggestions based on extensive integration testing and resulting search-algorithm proposals -- the most up-to-date feedback possible. Tim Carlin also provided comments and support for the document. Warren Kumari's review improved readability in several key passages. David Black, Martin Duke, and Scott Bradner's comments improved the clarity and configuration advice on trial duration. Mališa Vučinić suggested additional text on DUT design cautions in the Security Considerations section.
Trevor Cooper、Sridhar Rao、およびVSPERFプロジェクトのMartin Klozikのおかげで、早期テスト[VSPERF-B2B]に多くの貢献をしています。伊藤義昭もトピックを調査し、有用な提案をしました。Maciek KonstantyowiczとVratkoPolákも、広範囲の統合テストとその結果として生じる検索アルゴリズムの提案に基づく多くのコメントや提案を提供しました - 最新のフィードバックが可能です。Tim Carlinも文書のコメントとサポートを提供しました。Warren Kumariのレビューいくつかの主な継代における読みやすさを改善しました。David Black、Martin Duke、およびScott Bradnerのコメントは、試用期間に関する明快さと設定のアドバイスを改善しました。MalişaVušinićは、セキュリティ上の考慮事項のDUT設計注意に関する追加のテキストを提案しました。
Author's Address
著者の住所
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
Al Morton At＆T Labs 200 Laurel Avenue南Middletown、NJ 07748アメリカ合衆国
Phone: +1 732 420 1571
Email: acmorton@att.com