Internet Engineering Task Force (IETF) L. Ciavattone
Request for Comments: 6808 AT&T Labs
Category: Informational R. Geib
ISSN: 2070-1721 Deutsche Telekom
A. Morton
AT&T Labs
M. Wieser
Technical University Darmstadt
December 2012
Internet Engineering Task Force (IETF) L. Ciavattone
Request for Comments: 6808 AT&T Labs
Category: Informational R. Geib
ISSN: 2070-1721 Deutsche Telekom
A. Morton
AT&T Labs
M. Wieser
Technical University Darmstadt
December 2012
Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track
支持在标准轨道上推进RFC 2679的测试计划和结果
Abstract
摘要
This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679.
本备忘录提供了支持性测试计划和结果，以按照RFC 6576中的流程，在标准轨道上推进RFC 2679的单向延迟度量。注意到度量定义本身应该是主要焦点，而不是度量的实现，本备忘录描述了评估特定度量需求条款的测试程序，以确定需求是否按照预期进行了解释和实现。两个完全独立的实现已经根据RFC2679的关键规范进行了测试。本备忘录还为RFC 2679修订版的制定提供了直接输入。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc6808.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6808.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. A Definition-Centric Metric Advancement Process .................5
3. Test Configuration ..............................................5
4. Error Calibration, RFC 2679 .....................................9
4.1. NetProbe Error and Type-P .................................10
4.2. Perfas+ Error and Type-P ..................................12
5. Predetermined Limits on Equivalence ............................12
6. Tests to Evaluate RFC 2679 Specifications ......................13
6.1. One-Way Delay, ADK Sample Comparison: Same- and Cross-
Implementation ............................................13
6.1.1. NetProbe Same-Implementation Results ...............15
6.1.2. Perfas+ Same-Implementation Results ................16
6.1.3. One-Way Delay, Cross-Implementation ADK
Comparison .........................................16
6.1.4. Conclusions on the ADK Results for One-Way Delay ...17
6.1.5. Additional Investigations ..........................17
6.2. One-Way Delay, Loss Threshold, RFC 2679 ...................20
6.2.1. NetProbe Results for Loss Threshold ................21
6.2.2. Perfas+ Results for Loss Threshold .................21
6.2.3. Conclusions for Loss Threshold .....................21
6.3. One-Way Delay, First Bit to Last Bit, RFC 2679 ............21
6.3.1. NetProbe and Perfas+ Results for Serialization .....22
6.3.2. Conclusions for Serialization ......................23
6.4. One-Way Delay, Difference Sample Metric ...................24
6.4.1. NetProbe Results for Differential Delay ............24
6.4.2. Perfas+ Results for Differential Delay .............25
6.4.3. Conclusions for Differential Delay .................25
6.5. Implementation of Statistics for One-Way Delay ............25
7. Conclusions and RFC 2679 Errata ................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................27
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................28
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. A Definition-Centric Metric Advancement Process .................5
3. Test Configuration ..............................................5
4. Error Calibration, RFC 2679 .....................................9
4.1. NetProbe Error and Type-P .................................10
4.2. Perfas+ Error and Type-P ..................................12
5. Predetermined Limits on Equivalence ............................12
6. Tests to Evaluate RFC 2679 Specifications ......................13
6.1. One-Way Delay, ADK Sample Comparison: Same- and Cross-
Implementation ............................................13
6.1.1. NetProbe Same-Implementation Results ...............15
6.1.2. Perfas+ Same-Implementation Results ................16
6.1.3. One-Way Delay, Cross-Implementation ADK
Comparison .........................................16
6.1.4. Conclusions on the ADK Results for One-Way Delay ...17
6.1.5. Additional Investigations ..........................17
6.2. One-Way Delay, Loss Threshold, RFC 2679 ...................20
6.2.1. NetProbe Results for Loss Threshold ................21
6.2.2. Perfas+ Results for Loss Threshold .................21
6.2.3. Conclusions for Loss Threshold .....................21
6.3. One-Way Delay, First Bit to Last Bit, RFC 2679 ............21
6.3.1. NetProbe and Perfas+ Results for Serialization .....22
6.3.2. Conclusions for Serialization ......................23
6.4. One-Way Delay, Difference Sample Metric ...................24
6.4.1. NetProbe Results for Differential Delay ............24
6.4.2. Perfas+ Results for Differential Delay .............25
6.4.3. Conclusions for Differential Delay .................25
6.5. Implementation of Statistics for One-Way Delay ............25
7. Conclusions and RFC 2679 Errata ................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................27
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................28
The IETF IP Performance Metrics (IPPM) working group has considered how to advance their metrics along the Standards Track since 2001, with the initial publication of Bradner/Paxson/Mankin's memo [METRICS-TEST]. The original proposal was to compare the performance of metric implementations. This was similar to the usual procedures for advancing protocols, which did not directly apply. It was found to be difficult to achieve consensus on exactly how to compare implementations, since there were many legitimate sources of
自2001年以来，随着Bradner/Paxson/Mankin备忘录[Metrics-TEST]的首次发布，IETF IP性能度量（IPPM）工作组一直在考虑如何沿着标准轨道推进其度量。最初的建议是比较度量实现的性能。这与推进协议的常规程序类似，但并不直接适用。人们发现，很难就具体如何比较实施达成共识，因为存在许多合法的信息来源
variation that would emerge in the results despite the best attempts to keep the network paths equal, and because considerable variation was allowed in the parameters (and therefore implementation) of each metric. Flexibility in metric definitions, essential for customization and broad appeal, made the comparison task quite difficult.
尽管尽了最大努力保持网络路径相等，但结果中仍会出现变化，这是因为每个度量的参数（以及实现）允许存在相当大的变化。度量定义的灵活性对于定制和广泛的吸引力至关重要，这使得比较任务相当困难。
A renewed work effort investigated ways in which the measurement variability could be reduced and thereby simplify the problem of comparison for equivalence.
一项新的工作研究了减少测量可变性的方法，从而简化了等效性比较问题。
The consensus process documented in [RFC6576] is that metric definitions rather than the implementations of metrics should be the primary focus of evaluation. Equivalent test results are deemed to be evidence that the metric specifications are clear and unambiguous. This is now the metric specification equivalent of protocol interoperability. The [RFC6576] advancement process either produces confidence that the metric definitions and supporting material are clearly worded and unambiguous, or it identifies ways in which the metric definitions should be revised to achieve clarity.
[RFC6576]中记录的共识过程是，评估的主要焦点应该是度量定义，而不是度量的实现。等效试验结果被视为公制规范明确无误的证据。这现在是相当于协议互操作性的度量规范。[RFC6576]推进过程要么使人确信度量定义和支持材料的措辞清晰、明确，要么确定了为实现清晰性而修订度量定义的方式。
The metric RFC advancement process requires documentation of the testing and results. [RFC6576] retains the testing requirement of the original Standards Track advancement process described in [RFC2026] and [RFC5657], because widespread deployment is insufficient to determine whether RFCs that define performance metrics result in consistent implementations.
metric RFC推进过程要求记录测试和结果。[RFC6576]保留了[RFC2026]和[RFC5657]中描述的原始标准跟踪推进过程的测试要求，因为广泛部署不足以确定定义性能指标的RFC是否会导致一致的实施。
The process also permits identification of options that were not implemented, so that they can be removed from the advancing specification (this is a similar aspect to protocol advancement along the Standards Track). All errata must also be considered.
该过程还允许识别未实施的选项，以便将其从推进规范中删除（这与标准轨道上的协议推进类似）。还必须考虑所有勘误表。
This memo's purpose is to implement the advancement process of [RFC6576] for [RFC2679]. It supplies the documentation that accompanies the protocol action request submitted to the Area Director, including description of the test setup, results for each implementation, evaluation of each metric specification, and conclusions.
本备忘录旨在为[RFC2679]实施[RFC6576]的推进流程。它提供提交给区域主管的协议行动请求附带的文件，包括测试设置说明、每次实施的结果、每个度量规范的评估和结论。
In particular, this memo documents the consensus on the extent of tolerable errors when assessing equivalence in the results. The IPPM working group agreed that the test plan and procedures should include the threshold for determining equivalence, and that this aspect should be decided in advance of cross-implementation comparisons. This memo includes procedures for same-implementation comparisons that may influence the equivalence threshold.
特别是，本备忘录记录了评估结果等效性时可容忍误差范围的共识。IPPM工作组一致认为，测试计划和程序应包括确定等效性的阈值，并且应在交叉实施比较之前确定这一方面。本备忘录包括可能影响等效阈值的相同实现比较程序。
Although the conclusion reached through testing is that [RFC2679] should be advanced on the Standards Track with modifications, the revised text of RFC 2679 is not yet ready for review. Therefore, this memo documents the information to support [RFC2679] advancement, and the approval of a revision of RFC 2769 is left for future action.
尽管通过测试得出的结论是[RFC2679]应在标准轨道上进行修改，但RFC 2679的修订文本尚未准备好进行审查。因此，本备忘录记录了支持[RFC2679]进展的信息，RFC 2769修订版的批准留待将来采取行动。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
As a first principle, the process described in Section 3.5 of [RFC6576] takes the fact that the metric definitions (embodied in the text of the RFCs) are the objects that require evaluation and possible revision in order to advance to the next step on the Standards Track. This memo follows that process.
作为第一条原则，[RFC6576]第3.5节中描述的过程考虑到以下事实：度量定义（体现在RFC文本中）是需要评估和可能修订的对象，以便进入标准轨道上的下一步。本备忘录遵循这一过程。
One metric implementation used was NetProbe version 5.8.5 (an earlier version is used in AT&T's IP network performance measurement system and deployed worldwide [WIPM]). NetProbe uses UDP packets of variable size, and it can produce test streams with Periodic [RFC3432] or Poisson [RFC2330] sample distributions.
使用的一个度量实施是NetProbe版本5.8.5（AT&T的IP网络性能测量系统中使用了一个早期版本，并部署在全球[WIPM]）。NetProbe使用大小可变的UDP数据包，它可以生成具有周期性[RFC3432]或泊松[RFC2330]样本分布的测试流。
The other metric implementation used was Perfas+ version 3.1, developed by Deutsche Telekom [Perfas]. Perfas+ uses UDP unicast packets of variable size (but also supports TCP and multicast). Test streams with Periodic, Poisson, or uniform sample distributions may be used.
使用的另一个度量实现是由德国电信[Perfas]开发的Perfas+3.1版。Perfas+使用大小可变的UDP单播数据包（但也支持TCP和多播）。可以使用具有周期性、泊松分布或均匀样本分布的测试流。
Figure 1 shows a view of the test path as each implementation's test flows pass through the Internet and the Layer 2 Tunneling Protocol, version 3 (L2TPv3) tunnel IDs (1 and 2), based on Figures 2 and 3 of [RFC6576].
图1显示了基于[RFC6576]图2和图3的每个实现的测试流通过Internet和第2层隧道协议版本3（L2TPv3）隧道ID（1和2）时的测试路径视图。
+----+ +----+ +----+ +----+
|Imp1| |Imp1| ,---. |Imp2| |Imp2|
+----+ +----+ / \ +-------+ +----+ +----+
| V100 | V200 / \ | Tunnel| | V300 | V400
| | ( ) | Head | | |
+--------+ +------+ | |__| Router| +----------+
|Ethernet| |Tunnel| |Internet | +---B---+ |Ethernet |
|Switch |--|Head |-| | | |Switch |
+-+--+---+ |Router| | | +---+---+--+--+--+----+
|__| +--A---+ ( ) |Network| |__|
\ / |Emulat.|
U-turn \ / |"netem"| U-turn
V300 to V400 `-+-' +-------+ V100 to V200
+----+ +----+ +----+ +----+
|Imp1| |Imp1| ,---. |Imp2| |Imp2|
+----+ +----+ / \ +-------+ +----+ +----+
| V100 | V200 / \ | Tunnel| | V300 | V400
| | ( ) | Head | | |
+--------+ +------+ | |__| Router| +----------+
|Ethernet| |Tunnel| |Internet | +---B---+ |Ethernet |
|Switch |--|Head |-| | | |Switch |
+-+--+---+ |Router| | | +---+---+--+--+--+----+
|__| +--A---+ ( ) |Network| |__|
\ / |Emulat.|
U-turn \ / |"netem"| U-turn
V300 to V400 `-+-' +-------+ V100 to V200
Implementations ,---. +--------+
+~~~~~~~~~~~/ \~~~~~~| Remote |
+------->-----F2->-| / \ |->---. |
| +---------+ | Tunnel ( ) | | |
| | transmit|-F1->-| ID 1 ( ) |->. | |
| | Imp 1 | +~~~~~~~~~| |~~~~| | | |
| | receive |-<--+ ( ) | F1 F2 |
| +---------+ | |Internet | | | | |
*-------<-----+ F1 | | | | | |
+---------+ | | +~~~~~~~~~| |~~~~| | | |
| transmit|-* *-| | | |<-* | |
| Imp 2 | | Tunnel ( ) | | |
| receive |-<-F2-| ID 2 \ / |<----* |
+---------+ +~~~~~~~~~~~\ /~~~~~~| Switch |
`-+-' +--------+
Implementations ,---. +--------+
+~~~~~~~~~~~/ \~~~~~~| Remote |
+------->-----F2->-| / \ |->---. |
| +---------+ | Tunnel ( ) | | |
| | transmit|-F1->-| ID 1 ( ) |->. | |
| | Imp 1 | +~~~~~~~~~| |~~~~| | | |
| | receive |-<--+ ( ) | F1 F2 |
| +---------+ | |Internet | | | | |
*-------<-----+ F1 | | | | | |
+---------+ | | +~~~~~~~~~| |~~~~| | | |
| transmit|-* *-| | | |<-* | |
| Imp 2 | | Tunnel ( ) | | |
| receive |-<-F2-| ID 2 \ / |<----* |
+---------+ +~~~~~~~~~~~\ /~~~~~~| Switch |
`-+-' +--------+
Illustrations of a test setup with a bidirectional tunnel. The upper diagram emphasizes the VLAN connectivity and geographical location. The lower diagram shows example flows traveling between two measurement implementations (for simplicity, only two flows are shown).
带有双向通道的测试设置图示。上图强调了VLAN连接和地理位置。下图显示了两个测量实现之间的示例流（为简单起见，仅显示了两个流）。
Figure 1
图1
The testing employs the Layer 2 Tunneling Protocol, version 3 (L2TPv3) [RFC3931] tunnel between test sites on the Internet. The tunnel IP and L2TPv3 headers are intended to conceal the test equipment addresses and ports from hash functions that would tend to spread different test streams across parallel network resources, with likely variation in performance as a result.
测试采用第2层隧道协议，版本3（L2TPv3）[RFC3931]互联网上测试站点之间的隧道。隧道IP和L2TPv3报头旨在对哈希函数隐藏测试设备地址和端口，哈希函数可能会在并行网络资源中传播不同的测试流，从而可能导致性能变化。
At each end of the tunnel, one pair of VLANs encapsulated in the tunnel are looped back so that test traffic is returned to each test site. Thus, test streams traverse the L2TP tunnel twice, but appear to be one-way tests from the test equipment point of view.
在隧道的每一端，封装在隧道中的一对VLAN被环回，以便将测试流量返回到每个测试站点。因此，测试流穿过L2TP隧道两次，但从测试设备的角度来看，似乎是单向测试。
The network emulator is a host running Fedora 14 Linux [Fedora14] with IP forwarding enabled and the "netem" Network emulator [netem] loaded and operating as part of the Fedora Kernel 2.6.35.11. Connectivity across the netem/Fedora host was accomplished by bridging Ethernet VLAN interfaces together with "brctl" commands (e.g., eth1.100 <-> eth2.100). The netem emulator was activated on one interface (eth1) and only operates on test streams traveling in one direction. In some tests, independent netem instances operated separately on each VLAN.
网络仿真器是一台运行Fedora 14 Linux[Fedora14]并启用IP转发的主机，“netem”网络仿真器[netem]作为Fedora内核2.6.35.11的一部分加载并运行。通过桥接以太网VLAN接口和“brctl”命令（例如，eth1.100<->eth2.100），可实现netem/Fedora主机之间的连接。netem仿真器在一个接口（eth1）上被激活，并且仅对沿一个方向移动的测试流进行操作。在一些测试中，独立的netem实例分别在每个VLAN上运行。
The links between the netem emulator host and router and switch were found to be 100baseTx-HD (100 Mbps half duplex) when the testing was complete. Use of half duplex was not intended, but probably added a small amount of delay variation that could have been avoided in full duplex mode.
测试完成后，发现netem仿真器主机与路由器和交换机之间的链路为100baseTx HD（100 Mbps半双工）。不打算使用半双工，但可能会增加少量的延迟变化，这在全双工模式下是可以避免的。
Each individual test was run with common packet rates (1 pps, 10 pps) Poisson/Periodic distributions, and IP packet sizes of 64, 340, and 500 Bytes. These sizes cover a reasonable range while avoiding fragmentation and the complexities it causes, thus complying with the notion of "standard formed packets" described in Section 15 of [RFC2330].
每个单独的测试都是以常见的数据包速率（1 pps、10 pps）泊松/周期分布和64、340和500字节的IP数据包大小运行的。这些大小涵盖了一个合理的范围，同时避免了碎片及其造成的复杂性，因此符合[RFC2330]第15节中描述的“标准格式包”的概念。
For these tests, a stream of at least 300 packets were sent from Source to Destination in each implementation. Periodic streams (as per [RFC3432]) with 1 second spacing were used, except as noted.
对于这些测试，在每个实现中，从源到目标发送至少300个数据包的流。使用间隔1秒的周期性流（根据[RFC3432]），除非另有说明。
With the L2TPv3 tunnel in use, the metric name for the testing configured here (with respect to the IP header exposed to Internet processing) is:
在使用L2TPv3隧道的情况下，此处配置的测试的度量名称（关于暴露于Internet处理的IP头）为：
Type-IP-protocol-115-One-way-Delay-<StreamType>-Stream
Type-IP-protocol-115-单向延迟-<StreamType>-流
With (Section 4.2 of [RFC2679]) Metric Parameters:
使用（RFC2679第4.2节）公制参数：
+ Src, the IP address of a host (12.3.167.16 or 193.159.144.8)
+ Src，主机的IP地址（12.3.167.16或193.159.144.8）
+ Dst, the IP address of a host (193.159.144.8 or 12.3.167.16)
+ Dst，主机的IP地址（193.159.144.8或12.3.167.16）
+ T0, a time
+ T0，一次
+ Tf, a time
+ Tf，一次
+ lambda, a rate in reciprocal seconds
+ λ，以倒数秒为单位的速率
+ Thresh, a maximum waiting time in seconds (see Section 3.8.2 of [RFC2679] and Section 4.3 of [RFC2679])
+ Thresh，以秒为单位的最大等待时间（见[RFC2679]第3.8.2节和[RFC2679]第4.3节）
Metric Units: A sequence of pairs; the elements of each pair are:
公制单位：成对的序列；每对的元素包括：
+ T, a time, and
+ T、 一次，和
+ dT, either a real number or an undefined number of seconds.
+ dT，一个实数或未定义的秒数。
The values of T in the sequence are monotonic increasing. Note that T would be a valid parameter to Type-P-One-way-Delay and that dT would be a valid value of Type-P-One-way-Delay.
序列中T的值是单调递增的。注意，T将是Type-P-One-way-Delay的有效参数，dT将是Type-P-One-way-Delay的有效值。
Also, Section 3.8.4 of [RFC2679] recommends that the path SHOULD be reported. In this test setup, most of the path details will be concealed from the implementations by the L2TPv3 tunnels; thus, a more informative path trace route can be conducted by the routers at each location.
此外，[RFC2679]第3.8.4节建议报告路径。在该测试设置中，大部分路径细节将被L2TPv3隧道隐藏；因此，路由器可以在每个位置执行更具信息性的路径跟踪路由。
When NetProbe is used in production, a traceroute is conducted in parallel with, and at the outset of, measurements.
在生产中使用NetProbe时，跟踪路由与测量并行进行，并在测量开始时进行。
Perfas+ does not support traceroute.
Perfas+不支持跟踪路由。
IPLGW#traceroute 193.159.144.8
IPLGW#追踪路线193.159.144.8
Type escape sequence to abort. Tracing the route to 193.159.144.8
键入要中止的转义序列。追踪路线至193.159.144.8
1 12.126.218.245 [AS 7018] 0 msec 0 msec 4 msec 2 cr84.n54ny.ip.att.net (12.123.2.158) [AS 7018] 4 msec 4 msec cr83.n54ny.ip.att.net (12.123.2.26) [AS 7018] 4 msec 3 cr1.n54ny.ip.att.net (12.122.105.49) [AS 7018] 4 msec cr2.n54ny.ip.att.net (12.122.115.93) [AS 7018] 0 msec cr1.n54ny.ip.att.net (12.122.105.49) [AS 7018] 0 msec 4 n54ny02jt.ip.att.net (12.122.80.225) [AS 7018] 4 msec 0 msec n54ny02jt.ip.att.net (12.122.80.237) [AS 7018] 4 msec 5 192.205.34.182 [AS 7018] 0 msec 192.205.34.150 [AS 7018] 0 msec 192.205.34.182 [AS 7018] 4 msec 6 da-rg12-i.DA.DE.NET.DTAG.DE (62.154.1.30) [AS 3320] 88 msec 88 msec 88 msec 7 217.89.29.62 [AS 3320] 88 msec 88 msec 88 msec 8 217.89.29.55 [AS 3320] 88 msec 88 msec 88 msec 9 * * *
1 12.126.218.245[AS 7018]0 msec 0 msec 4 msec 2 cr84.n54ny.ip.att.net（12.123.2.158）[AS 7018]4 msec 4 msec cr83.n54ny.ip.att.net（12.123.2.26）[AS 7018]4 msec 3 cr1.n54ny.ip.att.net（12.122.105.49）[AS 7018]4 msec cr2.n54ny.ip.att.net（12.122.115.93]0毫秒4 n54ny02jt.ip.att.net（12.122.80.225）[AS 7018]4毫秒0毫秒n54ny02jt.ip.att.net（12.122.80.237）[AS 7018]4毫秒5 192.205.34.182[AS 7018]0毫秒192.205.34.150[AS 7018]0毫秒192.205.34.182[AS 7018]4毫秒6 da-rg12-i.da.DE.net.DTAG.DE（62.154.1.30）[AS 3320]88毫秒7.89]88毫秒88毫秒88毫秒8217.89.29.55[AS 3320]88毫秒88毫秒88毫秒9***
It was only possible to conduct the traceroute for the measured path on one of the tunnel-head routers (the normal trace facilities of the measurement systems are confounded by the L2TPv3 tunnel encapsulation).
只能在一个隧道头路由器上对测量路径进行跟踪路由（测量系统的正常跟踪设施被L2TPv3隧道封装混淆）。
An implementation is required to report on its error calibration in Section 3.8 of [RFC2679] (also required in Section 4.8 for sample metrics). Sections 3.6, 3.7, and 3.8 of [RFC2679] give the detailed formulation of the errors and uncertainties for calibration. In summary, Section 3.7.1 of [RFC2679] describes the total time-varying uncertainty as:
实施需要在[RFC2679]第3.8节中报告其误差校准情况（第4.8节中也要求对样本指标进行报告）。[RFC2679]第3.6、3.7和3.8节给出了校准误差和不确定度的详细公式。总之，[RFC2679]第3.7.1节将总时变不确定性描述为：
Esynch(t)+ Rsource + Rdest
Esynch(t)+ Rsource + Rdest
where:
哪里：
Esynch(t) denotes an upper bound on the magnitude of clock synchronization uncertainty.
Esynch（t）表示时钟同步不确定性大小的上限。
Rsource and Rdest denote the resolution of the source clock and the destination clock, respectively.
Rsource和Rdest分别表示源时钟和目标时钟的分辨率。
Further, Section 3.7.2 of [RFC2679] describes the total wire-time uncertainty as:
此外，[RFC2679]第3.7.2节将总导线时间不确定性描述为：
Hsource + Hdest
Hsource+Hdest
referring to the upper bounds on host-time to wire-time for source and destination, respectively.
分别参考源和目标的主机时间到连线时间的上限。
Section 3.7.3 of [RFC2679] describes a test with small packets over an isolated minimal network where the results can be used to estimate systematic and random components of the sum of the above errors or uncertainties. In a test with hundreds of singletons, the median is the systematic error and when the median is subtracted from all singletons, the remaining variability is the random error.
[RFC2679]第3.7.3节描述了在隔离最小网络上使用小数据包进行的测试，其结果可用于估计上述误差或不确定性总和的系统和随机分量。在一个有数百个单例的测试中，中位数是系统误差，当从所有单例中减去中位数时，剩余的变异性是随机误差。
The test context, or Type-P of the test packets, must also be reported, as required in Section 3.8 of [RFC2679] and all metrics defined there. Type-P is defined in Section 13 of [RFC2330] (as are many terms used below).
还必须按照[RFC2679]第3.8节的要求报告测试上下文或测试数据包的P型，以及其中定义的所有指标。[RFC2330]第13节对P型进行了定义（下文使用了许多术语）。
Type-P for this test was IP-UDP with Best Effort Differentiated Services Code Point (DSCP). These headers were encapsulated according to the L2TPv3 specifications [RFC3931]; thus, they may not influence the treatment received as the packets traversed the Internet.
此测试的P型是IP-UDP，带有尽力区分服务代码点（DSCP）。根据L2TPv3规范[RFC3931]对这些集管进行封装；因此，它们可能不会影响在分组穿越因特网时接收到的处理。
In general, NetProbe error is dependent on the specific version and installation details.
通常，NetProbe错误取决于特定版本和安装详细信息。
NetProbe operates using host-time above the UDP layer, which is different from the wire-time preferred in [RFC2330], but it can be identified as a source of error according to Section 3.7.2 of [RFC2679].
NetProbe使用UDP层上的主机时间进行操作，这与[RFC2330]中首选的连线时间不同，但根据[RFC2679]第3.7.2节，可以将其识别为错误源。
Accuracy of NetProbe measurements is usually limited by NTP synchronization performance (which is typically taken as ~+/-1 ms error or greater), although the installation used in this testing often exhibits errors much less than typical for NTP. The primary stratum 1 NTP server is closely located on a sparsely utilized network management LAN; thus, it avoids many concerns raised in Section 10 of [RFC2330] (in fact, smooth adjustment, long-term drift analysis and compensation, and infrequent adjustment all lead to stability during measurement intervals, the main concern).
NetProbe测量的准确性通常受到NTP同步性能的限制（通常被视为~+/-1 ms误差或更大），尽管此测试中使用的安装通常显示的误差远小于NTP的典型误差。主要的第1层NTP服务器紧密地位于使用率较低的网络管理LAN上；因此，它避免了[RFC2330]第10节中提出的许多问题（事实上，平滑调整、长期漂移分析和补偿以及不频繁调整都会导致测量间隔期间的稳定性，这是主要问题）。
The resolution of the reported results is 1 us (us = microsecond) in the version of NetProbe tested here, which contributes to at least +/-1 us error.
在此处测试的NetProbe版本中，报告结果的分辨率为1 us（us=微秒），这导致至少+/-1 us误差。
NetProbe implements a timekeeping sanity check on sending and receiving time-stamping processes. When a significant process interruption takes place, individual test packets are flagged as possibly containing unusual time errors, and they are excluded from the sample used for all "time" metrics.
NetProbe在发送和接收时间戳过程中执行计时健全性检查。当发生重大过程中断时，单个测试数据包被标记为可能包含异常时间错误，并且它们被排除在用于所有“时间”度量的样本之外。
We performed a NetProbe calibration of the type described in Section 3.7.3 of [RFC2679], using 64-Byte packets over a cross-connect cable. The results estimate systematic and random components of the sum of the Hsource + Hdest errors or uncertainties. In a test with 300 singletons conducted over 30 seconds (periodic sample with 100 ms spacing), the median is the systematic error and the remaining variability is the random error. One set of results is tabulated below:
我们使用交叉连接电缆上的64字节数据包，对[RFC2679]第3.7.3节中描述的类型进行了NetProbe校准。结果估计了Hsource+Hdest误差或不确定性总和的系统和随机分量。在30秒内进行的300个单例测试（间隔100 ms的周期性样本）中，中位数为系统误差，剩余的变异性为随机误差。一组结果如下表所示：
(Results from the "R" software environment for statistical computing
and graphics - http://www.r-project.org/ )
> summary(XD4CAL)
CAL1 CAL2 CAL3
Min. : 89.0 Min. : 68.00 Min. : 54.00
1st Qu.: 99.0 1st Qu.: 77.00 1st Qu.: 63.00
Median :110.0 Median : 79.00 Median : 65.00
Mean :116.8 Mean : 83.74 Mean : 69.65
3rd Qu.:127.0 3rd Qu.: 88.00 3rd Qu.: 74.00
Max. :205.0 Max. :177.00 Max. :163.00
>
NetProbe Calibration with Cross-Connect Cable, one-way delay values
in microseconds (us)
(Results from the "R" software environment for statistical computing
and graphics - http://www.r-project.org/ )
> summary(XD4CAL)
CAL1 CAL2 CAL3
Min. : 89.0 Min. : 68.00 Min. : 54.00
1st Qu.: 99.0 1st Qu.: 77.00 1st Qu.: 63.00
Median :110.0 Median : 79.00 Median : 65.00
Mean :116.8 Mean : 83.74 Mean : 69.65
3rd Qu.:127.0 3rd Qu.: 88.00 3rd Qu.: 74.00
Max. :205.0 Max. :177.00 Max. :163.00
>
NetProbe Calibration with Cross-Connect Cable, one-way delay values
in microseconds (us)
The median or systematic error can be as high as 110 us, and the range of the random error is also on the order of 116 us for all streams.
中值或系统误差可高达110 us，所有流的随机误差范围也在116 us左右。
Also, anticipating the Anderson-Darling K-sample (ADK) [ADK] comparisons to follow, we corrected the CAL2 values for the difference between the means of CAL2 and CAL3 (as permitted in Section 3.2 of [RFC6576]), and found strong support (for the Null Hypothesis) that the samples are from the same distribution (resolution of 1 us and alpha equal 0.05 and 0.01)
此外，预计接下来将进行Anderson-Darling K-sample（ADK）[ADK]比较，我们修正了CAL2和CAL3平均值之间的差异（如[RFC6576]第3.2节所允许），并发现样本来自相同分布的有力支持（对于零假设）（1 us和alpha的分辨率分别等于0.05和0.01）
> XD4CVCAL2 <- XD4CAL$CAL2 - (mean(XD4CAL$CAL2)-mean(XD4CAL$CAL3)) > boxplot(XD4CVCAL2,XD4CAL$CAL3) > XD4CV2_ADK <- adk.test(XD4CVCAL2, XD4CAL$CAL3) > XD4CV2_ADK Anderson-Darling k-sample test.
>XD4CVCAL2<-XD4CAL$CAL2-（平均值（XD4CAL$CAL2）-平均值（XD4CAL$CAL3））>箱线图（XD4CVCAL2，XD4CAL$CAL3）>XD4CV2_ADK<-ADK.测试（XD4CVCAL2，XD4CAL$CAL3）>XD4CV2_ADK安德森-达林k样本测试。
Number of samples: 2 Sample sizes: 300 300 Total number of values: 600 Number of unique values: 97
样本数：2个样本大小：300 300总值数：600唯一值数：97
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.75896
Anderson-Darling标准的平均值：1 Anderson-Darling标准的标准偏差：0.75896
T = (Anderson-Darling Criterion - mean)/sigma
T = (Anderson-Darling Criterion - mean)/sigma
Null Hypothesis: All samples come from a common population.
无效假设：所有样本均来自同一人群。
t.obs P-value extrapolation not adj. for ties 0.71734 0.17042 0 adj. for ties -0.39553 0.44589 1 > using [Rtool] and [Radk].
t、 obs P值外推不调整。对于系带0.71734 0.17042 0调整。对于领带-0.39553 0.44589 1>使用[Rtool]和[Radk]。
Perfas+ is configured to use GPS synchronization and uses NTP synchronization as a fall-back or default. GPS synchronization worked throughout this test with the exception of the calibration stated here (one implementation was NTP synchronized only). The time stamp accuracy typically is 0.1 ms.
Perfas+配置为使用GPS同步，并使用NTP同步作为回退或默认设置。GPS同步在整个测试过程中起作用，但此处所述的校准除外（仅一个实施为NTP同步）。时间戳精度通常为0.1 ms。
The resolution of the results reported by Perfas+ is 1 us (us = microsecond) in the version tested here, which contributes to at least +/-1 us error.
在此处测试的版本中，Perfas+报告的结果分辨率为1 us（us=微秒），这导致至少+/-1 us误差。
Port 5001 5002 5003 Min. -227 -226 294 Median -169 -167 323 Mean -159 -157 335 Max. 6 -52 376 s 102 102 93 Perfas+ Calibration with Cross-Connect Cable, one-way delay values in microseconds (us)
端口5001 5002 5003最小值-227-226 294中间值-169-167 323平均值-159-157 335最大值6-52 376 s 102 102 93性能+使用交叉连接电缆进行校准，单向延迟值以微秒（us）为单位
The median or systematic error can be as high as 323 us, and the range of the random error is also less than 232 us for all streams.
中值或系统误差可高达323 us，所有流的随机误差范围也小于232 us。
This section provides the numerical limits on comparisons between implementations, in order to declare that the results are equivalent and therefore, the tested specification is clear. These limits have their basis in Section 3.1 of [RFC6576] and the Appendix of [RFC2330], with additional limits representing IP Performance Metrics (IPPM) consensus prior to publication of results.
本节提供了实现之间比较的数值限制，以声明结果是等效的，因此，测试规范是明确的。这些限值以[RFC6576]第3.1节和[RFC2330]附录为依据，附加限值表示结果发布前的IP性能指标（IPPM）共识。
A key point is that the allowable errors, corrections, and confidence levels only need to be sufficient to detect misinterpretation of the tested specification resulting in diverging implementations.
一个关键点是，允许的误差、修正和置信水平只需要足以检测对测试规范的误解，从而导致不同的实现。
Also, the allowable error must be sufficient to compensate for measured path differences. It was simply not possible to measure fully identical paths in the VLAN-loopback test configuration used, and this practical compromise must be taken into account.
此外，允许误差必须足以补偿测量的路径差异。在所使用的VLAN环回测试配置中，根本不可能测量完全相同的路径，必须考虑这种实际的折衷。
For Anderson-Darling K-sample (ADK) comparisons, the required confidence factor for the cross-implementation comparisons SHALL be the smallest of:
对于Anderson-Darling K样本（ADK）比较，交叉实施比较所需的置信因子应为以下最小值：
o 0.95 confidence factor at 1 ms resolution, or
o 1毫秒分辨率下的0.95置信系数，或
o the smallest confidence factor (in combination with resolution) of the two same-implementation comparisons for the same test conditions.
o 相同测试条件下两个相同实施比较的最小置信因子（结合分辨率）。
A constant time accuracy error of as much as +/-0.5 ms MAY be removed from one implementation's distributions (all singletons) before the ADK comparison is conducted.
在进行ADK比较之前，可以从一个实现的分布（所有单态）中消除高达+/-0.5 ms的恒定时间精度误差。
A constant propagation delay error (due to use of different sub-nets between the switch and measurement devices at each location) of as much as +2 ms MAY be removed from one implementation's distributions (all singletons) before the ADK comparison is conducted.
在进行ADK比较之前，可以从一个实现的分布（所有单例）中消除高达+2 ms的恒定传播延迟误差（由于在每个位置的交换机和测量设备之间使用不同的子网）。
For comparisons involving the mean of a sample or other central statistics, the limits on both the time accuracy error and the propagation delay error constants given above also apply.
对于涉及样本平均值或其他中心统计数据的比较，上述时间精度误差和传播延迟误差常数的限制也适用。
This section describes some results from real-world (cross-Internet) tests with measurement devices implementing IPPM metrics and a network emulator to create relevant conditions, to determine whether the metric definitions were interpreted consistently by implementors.
本节描述了现实世界（跨互联网）测试的一些结果，这些测试使用实现IPPM度量的测量设备和网络仿真器来创建相关条件，以确定度量定义是否由实现者一致解释。
The procedures are slightly modified from the original procedures contained in Appendix A.1 of [RFC6576]. The modifications include the use of the mean statistic for comparisons.
这些程序与[RFC6576]附录A.1中的原始程序略有不同。修改包括使用平均统计进行比较。
Note that there are only five instances of the requirement term "MUST" in [RFC2679] outside of the boilerplate and [RFC2119] reference.
请注意，[RFC2679]中除样板和[RFC2119]参考文献外，仅有五个需求术语“必须”的实例。
6.1. One-Way Delay, ADK Sample Comparison: Same- and Cross-Implementation
6.1. 单向延迟，ADK样本比较：相同和交叉实现
This test determines if implementations produce results that appear to come from a common delay distribution, as an overall evaluation of Section 4 of [RFC2679], "A Definition for Samples of One-way Delay". Same-implementation comparison results help to set the threshold of equivalence that will be applied to cross-implementation comparisons.
作为[RFC2679]“单向延迟样本的定义”第4节的总体评估，该测试确定实施是否产生了来自公共延迟分布的结果。相同的实现比较结果有助于设置将应用于跨实现比较的等效阈值。
This test is intended to evaluate measurements in Sections 3 and 4 of [RFC2679].
本试验旨在评估[RFC2679]第3节和第4节中的测量值。
By testing the extent to which the distributions of one-way delay singletons from two implementations of [RFC2679] appear to be from the same distribution, we economize on comparisons, because comparing a set of individual summary statistics (as defined in Section 5 of [RFC2679]) would require another set of individual evaluations of equivalence. Instead, we can simply check which statistics were implemented, and report on those facts.
通过测试[RFC2679]的两个实现的单向延迟单例分布似乎来自同一分布的程度，我们节省了比较，因为比较一组单独的汇总统计数据（如[RFC2679]第5节所定义）将需要另一组单独的等效性评估。相反，我们可以简单地检查实施了哪些统计数据，并报告这些事实。
1. Configure an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs.
1. 在测试站点和每对测量设备之间配置L2TPv3路径，以在其指定的VLAN对中运行测试。
2. Measure a sample of one-way delay singletons with two or more implementations, using identical options and network emulator settings (if used).
2. 使用相同的选项和网络仿真器设置（如果使用），测量具有两个或多个实现的单向延迟单例示例。
3. Measure a sample of one-way delay singletons with *four* instances of the *same* implementations, using identical options, noting that connectivity differences SHOULD be the same as for the cross-implementation testing.
3. 使用相同的选项测量具有*相同*实现的*四个*实例的单向延迟单例样本，注意连接差异应与交叉实现测试相同。
4. Apply the ADK comparison procedures (see Appendices A and B of [RFC6576]) and determine the resolution and confidence factor for distribution equivalence of each same-implementation comparison and each cross-implementation comparison.
4. 应用ADK比较程序（见[RFC6576]附录A和B），并确定每个相同实施比较和每个交叉实施比较的分布等效性的分辨率和置信因子。
5. Take the coarsest resolution and confidence factor for distribution equivalence from the same-implementation pairs, or the limit defined in Section 5 above, as a limit on the equivalence threshold for these experimental conditions.
5. 将相同实现对中分布等效性的最粗略分辨率和置信因子，或上文第5节中定义的限制，作为这些实验条件下等效阈值的限制。
6. Apply constant correction factors to all singletons of the sample distributions, as described and limited in Section 5 above.
6. 如上文第5节所述，对样本分布的所有单例应用常数修正系数。
7. Compare the cross-implementation ADK performance with the equivalence threshold determined in step 5 to determine if equivalence can be declared.
7. 将交叉实现ADK性能与步骤5中确定的等效阈值进行比较，以确定是否可以声明等效性。
The common parameters used for tests in this section are:
本节中用于测试的通用参数为：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Periodic sampling at 1 packet per second
o 以每秒1包的速度进行定期采样
o Test duration = 300 seconds (March 29, 2011)
o 测试持续时间=300秒（2011年3月29日）
The netem emulator was set for 100 ms average delay, with uniform delay variation of +/-50 ms. In this experiment, the netem emulator was configured to operate independently on each VLAN; thus, the emulator itself is a potential source of error when comparing streams that traverse the test path in different directions.
netem仿真器的平均延迟设置为100毫秒，平均延迟变化为+/-50毫秒。在本实验中，netem仿真器被配置为在每个VLAN上独立运行；因此，在比较沿不同方向穿过测试路径的流时，仿真器本身是一个潜在的错误源。
In the result analysis of this section:
在本节的结果分析中：
o All comparisons used 1 microsecond resolution.
o 所有比较均使用1微秒分辨率。
o No correction factors were applied.
o 未应用校正因子。
o The 0.95 confidence factor (1.960 for paired stream comparison) was used.
o 采用0.95置信因子（配对流比较为1.960）。
A single same-implementation comparison fails the ADK criterion (s1 <-> sB). We note that these streams traversed the test path in opposite directions, making the live network factors a possibility to explain the difference.
单个相同的实现比较不符合ADK标准（s1<->sB）。我们注意到，这些流以相反的方向穿过测试路径，使得实时网络因素成为解释差异的可能。
All other pair comparisons pass the ADK criterion.
所有其他对比较都通过ADK标准。
+------------------------------------------------------+
| | | | |
| ti.obs (P) | s1 | s2 | sA |
| | | | |
.............|.............|.............|.............|
| | | | |
| s2 | 0.25 (0.28) | | |
| | | | |
...........................|.............|.............|
| | | | |
| sA | 0.60 (0.19) |-0.80 (0.57) | |
| | | | |
...........................|.............|.............|
| | | | |
| sB | 2.64 (0.03) | 0.07 (0.31) |-0.52 (0.48) |
| | | | |
+------------+-------------+-------------+-------------+
+------------------------------------------------------+
| | | | |
| ti.obs (P) | s1 | s2 | sA |
| | | | |
.............|.............|.............|.............|
| | | | |
| s2 | 0.25 (0.28) | | |
| | | | |
...........................|.............|.............|
| | | | |
| sA | 0.60 (0.19) |-0.80 (0.57) | |
| | | | |
...........................|.............|.............|
| | | | |
| sB | 2.64 (0.03) | 0.07 (0.31) |-0.52 (0.48) |
| | | | |
+------------+-------------+-------------+-------------+
NetProbe ADK results for same-implementation
相同实现的NetProbe ADK结果
All pair comparisons pass the ADK criterion.
所有对比较都通过ADK标准。
+------------------------------------------------------+
| | | | |
| ti.obs (P) | p1 | p2 | p3 |
| | | | |
.............|.............|.............|.............|
| | | | |
| p2 | 0.06 (0.32) | | |
| | | | |
.........................................|.............|
| | | | |
| p3 | 1.09 (0.12) | 0.37 (0.24) | |
| | | | |
...........................|.............|.............|
| | | | |
| p4 |-0.81 (0.57) |-0.13 (0.37) | 1.36 (0.09) |
| | | | |
+------------+-------------+-------------+-------------+
+------------------------------------------------------+
| | | | |
| ti.obs (P) | p1 | p2 | p3 |
| | | | |
.............|.............|.............|.............|
| | | | |
| p2 | 0.06 (0.32) | | |
| | | | |
.........................................|.............|
| | | | |
| p3 | 1.09 (0.12) | 0.37 (0.24) | |
| | | | |
...........................|.............|.............|
| | | | |
| p4 |-0.81 (0.57) |-0.13 (0.37) | 1.36 (0.09) |
| | | | |
+------------+-------------+-------------+-------------+
Perfas+ ADK results for same-implementation
相同实现的性能+ADK结果
The cross-implementation results are compared using a combined ADK analysis [Radk], where all NetProbe results are compared with all Perfas+ results after testing that the combined same-implementation results pass the ADK criterion.
使用组合ADK分析[Radk]比较交叉实施结果，在测试组合相同实施结果通过ADK标准后，将所有NetProbe结果与所有Perfas+结果进行比较。
When 4 (same) samples are compared, the ADK criterion for 0.95 confidence is 1.915, and when all 8 (cross) samples are compared it is 1.85.
比较4个（相同）样本时，0.95置信度的ADK标准为1.915，比较所有8个（交叉）样本时，ADK标准为1.85。
Combination of Anderson-Darling K-Sample Tests.
Anderson-Darling K样本测试的组合。
Sample sizes within each data set: Data set 1 : 299 297 298 300 (NetProbe) Data set 2 : 300 300 298 300 (Perfas+) Total sample size per data set: 1194 1198 Number of unique values per data set: 1188 1192 ... Null Hypothesis: All samples within a data set come from a common distribution. The common distribution may change between data sets.
每个数据集中的样本大小：数据集1:299 297 298 300（NetProbe）数据集2:300 300 298 300（Perfas+）每个数据集的总样本大小：1194 1198每个数据集的唯一值数：1188 1192。。。零假设：一个数据集中的所有样本都来自同一个分布。数据集之间的公共分布可能会发生变化。
NetProbe ti.obs P-value extrapolation not adj. for ties 0.64999 0.21355 0 adj. for ties 0.64833 0.21392 0 Perfas+ not adj. for ties 0.55968 0.23442 0 adj. for ties 0.55840 0.23473 0
NetProbe ti.obs P值外推不调整。对于系带0.64999 0.21355 0调整。对于0.64833 0.21392 0性能+不调整。对于系带0.55968 0.23442 0调整。对于系带0.55840 0.23473 0
Combined Anderson-Darling Criterion: tc.obs P-value extrapolation not adj. for ties 0.85537 0.17967 0 adj. for ties 0.85329 0.18010 0
联合Anderson-Darling标准：tc.obs P值外推不调整。对于系带0.85537 0.17967 0调整。系材0.85329 0.18010 0
The combined same-implementation samples and the combined cross-implementation comparison all pass the ADK criterion at P>=0.18 and support the Null Hypothesis (both data sets come from a common distribution).
组合的相同实现样本和组合的交叉实现比较都在P>=0.18时通过了ADK标准，并支持零假设（两个数据集来自一个共同的分布）。
We also see that the paired ADK comparisons are rather critical. Although the NetProbe s1-sB comparison failed, the combined data set from four streams passed the ADK criterion easily.
我们还看到成对的ADK比较非常关键。尽管NetProbe s1 sB比较失败，但来自四个流的组合数据集很容易通过ADK标准。
Similar testing was repeated many times in the months of March and April 2011. There were many experiments where a single test stream from NetProbe or Perfas+ proved to be different from the others in paired comparisons (even same-implementation comparisons). When the outlier stream was removed from the comparison, the remaining streams passed combined ADK criterion. Also, the application of correction factors resulted in higher comparison success.
类似的测试在2011年3月和4月重复了很多次。有许多实验证明，来自NetProbe或Perfas+的单个测试流在成对比较中不同于其他测试流（甚至是相同的实现比较）。当从比较中删除异常数据流时，其余数据流通过组合ADK标准。此外，校正因子的应用导致了更高的比较成功率。
We conclude that the two implementations are capable of producing equivalent one-way delay distributions based on their interpretation of [RFC2679].
我们得出结论，这两种实现能够根据[RFC2679]的解释产生等效的单向延迟分布。
On the final day of testing, we performed a series of measurements to evaluate the amount of emulated delay variation necessary to achieve successful ADK comparisons. The need for correction factors (as permitted by Section 5) and the size of the measurement sample (obtained as sub-sets of the complete measurement sample) were also evaluated.
在测试的最后一天，我们进行了一系列测量，以评估实现成功ADK比较所需的模拟延迟变化量。还评估了校正系数的需要（如第5节所允许）和测量样本的大小（作为完整测量样本的子集获得）。
The common parameters used for tests in this section are:
本节中用于测试的通用参数为：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Periodic sampling at 1 packet per second
o 以每秒1包的速度进行定期采样
o Test duration = 300 seconds at each delay variation setting, for a total of 1200 seconds (May 2, 2011 at 1720 UTC)
o 在每个延迟变化设置下，测试持续时间=300秒，总计1200秒（2011年5月2日，协调世界时1720分）
The netem emulator was set for 100 ms average delay, with (emulated) uniform delay variation of:
netem仿真器的平均延迟设置为100 ms，（模拟的）均匀延迟变化为：
o +/-7.5 ms
o +/-7.5毫秒
o +/-5.0 ms
o +/-5.0毫秒
o +/-2.5 ms
o +/-2.5毫秒
o 0 ms
o 0毫秒
In this experiment, the netem emulator was configured to operate independently on each VLAN; thus, the emulator itself is a potential source of error when comparing streams that traverse the test path in different directions.
在本实验中，netem模拟器被配置为在每个VLAN上独立运行；因此，在比较沿不同方向穿过测试路径的流时，仿真器本身是一个潜在的错误源。
In the result analysis of this section:
在本节的结果分析中：
o All comparisons used 1 microsecond resolution.
o 所有比较均使用1微秒分辨率。
o Correction factors *were* applied as noted (under column heading "mean adj"). The difference between each sample mean and the lowest mean of the NetProbe or Perfas+ stream samples was subtracted from all values in the sample. ("raw" indicates no correction factors were used.) All correction factors applied met the limits described in Section 5.
o 如注释所述，采用了校正系数*（在“平均调整”列标题下）。从样本中的所有值中减去每个样本平均值与NetProbe或Perfas+流样本的最低平均值之间的差值。（“原始”表示未使用校正系数。）所有应用的校正系数均符合第5节中所述的限值。
o The 0.95 confidence factor (1.960 for paired stream comparison) was used.
o 采用0.95置信因子（配对流比较为1.960）。
When 8 (cross) samples are compared, the ADK criterion for 0.95 confidence is 1.85. The Combined ADK test statistic ("TC observed") must be less than 1.85 to accept the Null Hypothesis (all samples in the data set are from a common distribution).
当比较8个（交叉）样本时，0.95置信度的ADK标准为1.85。组合ADK检验统计量（“观察到的TC”）必须小于1.85才能接受零假设（数据集中的所有样本均来自同一分布）。
Emulated Delay Sub-Sample size Variation 0ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 226.6563 67.51559 54.01359 21.56513 P-value 0 0 0 0 Mean std dev (all),us 719 635 Mean diff of means,us 649 0 606 0
模拟延迟子样本大小变化0ms adk。组合（全部）300个值75个值调整。对于领带，观察到的原始平均值调整原始平均值调整TC 226.6563 67.51559 54.01359 21.56513 P值0 0 0 0 0平均标准偏差（全部），美国719 635平均差异，美国649 0 606 0
Variation +/- 2.5ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 14.50436 -1.60196 3.15935 -1.72104 P-value 0 0.873 0.00799 0.89038 Mean std dev (all),us 1655 1702 Mean diff of means,us 471 0 513 0
变化+/-2.5ms adk组合（全部）300个值75个值调整。对于领带，观察到的原始平均值调整原始平均值调整TC 14.50436-1.60196 3.15935-1.72104 P值0.873 0.00799 0.89038平均标准偏差（全部），美国1655 1702平均差异，美国471 0 513 0
Variation +/- 5ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 8.29921 -1.28927 0.37878 -1.81881 P-value 0 0.81601 0.29984 0.90305 Mean std dev (all),us 3023 2991 Mean diff of means,us 582 0 513 0
变化+/-5ms adk组合（全部）300个值75个值调整。对于领带，观察到的原始平均值调整原始平均值调整TC 8.29921-1.28927 0.37878-1.81881 P值0.81601 0.29984 0.90305平均标准偏差（全部），美国3023 2991平均差异，美国582 0 513 0
Variation +/- 7.5ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 2.53759 -0.72985 0.29241 -1.15840 P-value 0.01950 0.66942 0.32585 0.78686 Mean std dev (all),us 4449 4506 Mean diff of means,us 426 0 856 0
变化+/-7.5ms adk组合（全部）300个值75个值调整。对于领带，观察到的原始平均值调整原始平均值调整TC 2.53759-0.72985 0.29241-1.15840 P值0.01950 0.66942 0.32585 0.78686平均标准偏差（all），美国4449 4506平均偏差，美国426 0 856 0
From the table above, we conclude the following:
根据上表，我们得出以下结论：
1. None of the raw or mean adjusted results pass the ADK criterion with 0 ms emulated delay variation. Use of the 75 value sub-sample yielded the same conclusion. (We note the same results when comparing same-implementation samples for both NetProbe and Perfas+.)
1. 原始或平均调整结果均未通过ADK标准，模拟延迟变化为0 ms。使用75值子样本得出了相同的结论。（在比较NetProbe和Perfas+的相同实现示例时，我们注意到相同的结果。）
2. When the smallest emulated delay variation was inserted (+/-2.5 ms), the mean adjusted samples pass the ADK criterion and the high P-value supports the result. The raw results do not pass.
2. 当插入最小模拟延迟变化（+/-2.5 ms）时，平均调整样本通过ADK标准，高P值支持结果。原始结果无法通过。
3. At higher values of emulated delay variation (+/-5.0 ms and +/-7.5 ms), again the mean adjusted values pass ADK. We also see that the 75-value sub-sample passed the ADK in both raw and mean adjusted cases. This indicates that sample size may have played a role in our results, as noted in the Appendix of [RFC2330] for Goodness-of-Fit testing.
3. 在较高的模拟延迟变化值（+/-5.0 ms和+/-7.5 ms）下，平均调整值再次通过ADK。我们还看到，在原始和平均调整情况下，75值子样本通过ADK。这表明样本量可能在我们的结果中起了作用，如[RFC2330]中关于拟合优度测试的附录所述。
We note that 150 value sub-samples were also evaluated, with ADK conclusions that followed the results for 300 values. Also, same-implementation analysis was conducted with results similar to the above, except that more of the "raw" or uncorrected samples passed the ADK criterion.
我们注意到，还评估了150个值子样本，ADK结论与300个值的结果一致。此外，进行了相同的实施分析，结果与上述类似，但更多的“原始”或未修正样本通过了ADK标准。
This test determines if implementations use the same configured maximum waiting time delay from one measurement to another under different delay conditions, and correctly declare packets arriving in excess of the waiting time threshold as lost.
该测试确定实现是否在不同的延迟条件下使用相同配置的最大等待时间延迟（从一个测量到另一个测量），并正确地将超过等待时间阈值到达的数据包声明为丢失。
See the requirements of Section 3.5 of [RFC2679], third bullet point, and also Section 3.8.2 of [RFC2679].
参见[RFC2679]第3.5节、第三个要点以及[RFC2679]第3.8.2节的要求。
1. configure an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs.
1. 在测试站点和每对测量设备之间配置L2TPv3路径，以在其指定的VLAN对中运行测试。
2. configure the network emulator to add 1.0 sec. one-way constant delay in one direction of transmission.
2. 将网络仿真器配置为添加1.0秒。单向传输方向上的单向恒定延迟。
3. measure (average) one-way delay with two or more implementations, using identical waiting time thresholds (Thresh) for loss set at 3 seconds.
3. 使用相同的等待时间阈值（Thresh）测量两个或多个实现的（平均）单向延迟，将损耗设置为3秒。
4. configure the network emulator to add 3 sec. one-way constant delay in one direction of transmission equivalent to 2 seconds of additional one-way delay (or change the path delay while test is in progress, when there are sufficient packets at the first delay setting).
4. 将网络仿真器配置为添加3秒。一个传输方向上的单向恒定延迟，相当于2秒的额外单向延迟（或在测试进行时，当第一个延迟设置有足够的数据包时，更改路径延迟）。
5. repeat/continue measurements.
5. 重复/继续测量。
6. observe that the increase measured in step 5 caused all packets with 2 sec. additional delay to be declared lost, and that all packets that arrive successfully in step 3 are assigned a valid one-way delay.
6. 注意，步骤5中测量到的增加导致所有数据包都有2秒的时间。要声明丢失的额外延迟，并且在步骤3中成功到达的所有数据包都被分配了有效的单向延迟。
The common parameters used for tests in this section are:
本节中用于测试的通用参数为：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Poisson sampling at lambda = 1 packet per second
o lambda=每秒1个数据包时的泊松采样
o Test duration = 900 seconds total (March 21, 2011)
o 测试持续时间=总共900秒（2011年3月21日）
The netem emulator was set to add constant delays as specified in the procedure above.
netem仿真器设置为添加上述过程中指定的恒定延迟。
In NetProbe, the Loss Threshold is implemented uniformly over all packets as a post-processing routine. With the Loss Threshold set at 3 seconds, all packets with one-way delay >3 seconds are marked "Lost" and included in the Lost Packet list with their transmission time (as required in Section 3.3 of [RFC2680]). This resulted in 342 packets designated as lost in one of the test streams (with average delay = 3.091 sec.).
在NetProbe中，丢失阈值作为后处理例程在所有数据包上统一实现。在丢失阈值设置为3秒的情况下，所有单向延迟>3秒的数据包都标记为“丢失”，并包括在丢失数据包列表中及其传输时间（如[RFC2680]第3.3节所要求）。这导致342个数据包在其中一个测试流中被指定为丢失（平均延迟=3.091秒）。
Perfas+ uses a fixed Loss Threshold that was not adjustable during this study. The Loss Threshold is approximately one minute, and emulation of a delay of this size was not attempted. However, it is possible to implement any delay threshold desired with a post-processing routine and subsequent analysis. Using this method, 195 packets would be declared lost (with average delay = 3.091 sec.).
Perfas+使用了一个在本研究期间不可调整的固定损失阈值。损失阈值约为一分钟，未尝试模拟此大小的延迟。然而，可以通过后处理例程和后续分析实现所需的任何延迟阈值。使用此方法，195个数据包将被宣布丢失（平均延迟=3.091秒）。
Both implementations assume that any constant delay value desired can be used as the Loss Threshold, since all delays are stored as a pair <Time, Delay> as required in [RFC2679]. This is a simple way to enforce the constant loss threshold envisioned in [RFC2679] (see specific section references above). We take the position that the assumption of post-processing is compliant and that the text of the RFC should be revised slightly to include this point.
这两种实现都假设任何期望的恒定延迟值都可以用作损失阈值，因为所有延迟都按照[RFC2679]中的要求成对存储<Time，delay>。这是一种实施[RFC2679]中设想的恒定损耗阈值的简单方法（见上文特定章节参考）。我们的立场是，后处理的假设是符合的，RFC的文本应该稍微修改，以包括这一点。
This test determines if implementations register the same relative change in delay from one packet size to another, indicating that the first-to-last time-stamping convention has been followed. This test tends to cancel the sources of error that may be present in an implementation.
此测试确定实现是否记录了从一个数据包大小到另一个数据包大小的相同延迟相对变化，表明遵循了从第一个到最后一个时间戳约定。此测试倾向于取消实现中可能存在的错误源。
See the requirements of Section 3.7.2 of [RFC2679], and Section 10.2 of [RFC2330].
参见[RFC2679]第3.7.2节和[RFC2330]第10.2节的要求。
1. configure an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs, and ideally including a low-speed link (it was not possible to change the link configuration during testing, so the lowest speed link present was the basis for serialization time comparisons).
1. 在测试站点和每对测量设备之间配置L2TPv3路径，以在其指定的VLAN对中运行测试，理想情况下包括低速链路（在测试期间不可能更改链路配置，因此存在的最低速度链路是序列化时间比较的基础）。
2. measure (average) one-way delay with two or more implementations, using identical options and equal size small packets (64-octet IP header and payload).
2. 使用相同的选项和相同大小的小数据包（64个八位组的IP报头和有效负载），通过两个或多个实现测量（平均）单向延迟。
3. maintain the same path with additional emulated 100 ms one-way delay.
3. 以额外的模拟100毫秒单向延迟保持相同的路径。
4. measure (average) one-way delay with two or more implementations, using identical options and equal size large packets (500 octet IP header and payload).
4. 使用相同的选项和相同大小的大数据包（500个八位组IP报头和有效负载），通过两个或多个实现测量（平均）单向延迟。
5. observe that the increase measured between steps 2 and 4 is equivalent to the increase in ms expected due to the larger serialization time for each implementation. Most of the measurement errors in each system should cancel, if they are stationary.
5. 请注意，由于每个实现的序列化时间较长，在步骤2和步骤4之间测得的增加量与预期的毫秒增加量相等。如果每个系统中的大多数测量误差是静止的，那么它们应该被消除。
The common parameters used for tests in this section are:
本节中用于测试的通用参数为：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Periodic sampling at l packet per second
o 以每秒l个数据包的速度进行定期采样
o Test duration = 300 seconds total (April 12)
o 测试持续时间=总共300秒（4月12日）
The netem emulator was set to add constant 100 ms delay.
netem仿真器设置为添加恒定的100毫秒延迟。
When the IP header + payload size was increased from 64 octets to 500 octets, there was a delay increase observed.
当IP头+有效负载大小从64个八位字节增加到500个八位字节时，观察到延迟增加。
Mean Delays in us NetProbe Payload s1 s2 sA sB 500 190893 191179 190892 190971 64 189642 189785 189747 189467 Diff 1251 1394 1145 1505
美国NetProbe有效载荷s1 s2 sA sB 500 190893 191179 190892 190971 64 189642 189785 189747 189467差异1251 1394 1145 1505的平均延迟
Perfas Payload p1 p2 p3 p4 500 190908 190911 191126 190709 64 189706 189752 189763 190220 Diff 1202 1159 1363 489
性能有效载荷p1 p2 p3 p4 500 190908 190911 191126 190709 64 189706 189752 189763 190220差异1202 1159 1363 489
Serialization tests, all values in microseconds
序列化测试，所有值以微秒为单位
The typical delay increase when the larger packets were used was 1.1 to 1.5 ms (with one outlier). The typical measurements indicate that a link with approximately 3 Mbit/s capacity is present on the path.
当使用较大的数据包时，典型的延迟增加为1.1到1.5毫秒（有一个异常值）。典型测量表明，路径上存在容量约为3 Mbit/s的链路。
Through investigation of the facilities involved, it was determined that the lowest speed link was approximately 45 Mbit/s, and therefore the estimated difference should be about 0.077 ms. The observed differences are much higher.
通过对相关设施的调查，确定最低速度链路约为45 Mbit/s，因此估计差异应为0.077 ms。观察到的差异要高得多。
The unexpected large delay difference was also the outcome when testing serialization times in a lab environment, using the NIST Net Emulator and NetProbe [ADV-METRICS].
使用NIST网络仿真器和NetProbe[ADV-METRICS]在实验室环境中测试序列化时间时，也会出现意外的大延迟差异。
Since it was not possible to confirm the estimated serialization time increases in field tests, we resort to examination of the implementations to determine compliance.
由于不可能在现场测试中确认估计的序列化时间增加，我们求助于检查实现以确定符合性。
NetProbe performs all time stamping above the IP layer, accepting that some compromises must be made to achieve extreme portability and measurement scale. Therefore, the first-to-last bit convention is supported because the serialization time is included in the one-way delay measurement, enabling comparison with other implementations.
NetProbe在IP层上执行所有时间戳，接受必须做出一些妥协以实现极端的可移植性和测量规模。因此，支持从第一位到最后一位的约定，因为串行化时间包含在单向延迟测量中，可以与其他实现进行比较。
Perfas+ is optimized for its purpose and performs all time stamping close to the interface hardware. The first-to-last bit convention is supported because the serialization time is included in the one-way delay measurement, enabling comparison with other implementations.
Perfas+针对其用途进行了优化，并在接近接口硬件的位置执行所有时间戳。支持从第一位到最后一位的约定，因为串行化时间包含在单向延迟测量中，可以与其他实现进行比较。
This test determines if implementations register the same relative increase in delay from one measurement to another under different delay conditions. This test tends to cancel the sources of error that may be present in an implementation.
该测试确定在不同的延迟条件下，实现是否记录了从一个测量到另一个测量的相同相对延迟增加。此测试倾向于取消实现中可能存在的错误源。
This test is intended to evaluate measurements in Sections 3 and 4 of [RFC2679].
本试验旨在评估[RFC2679]第3节和第4节中的测量值。
1. configure an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs.
1. 在测试站点和每对测量设备之间配置L2TPv3路径，以在其指定的VLAN对中运行测试。
2. measure (average) one-way delay with two or more implementations, using identical options.
2. 使用相同的选项，通过两个或多个实现测量（平均）单向延迟。
3. configure the path with X+Y ms one-way delay.
3. 配置具有X+Y毫秒单向延迟的路径。
4. repeat measurements.
4. 重复测量。
5. observe that the (average) increase measured in steps 2 and 4 is ~Y ms for each implementation. Most of the measurement errors in each system should cancel, if they are stationary.
5. 观察在步骤2和步骤4中测量到的（平均）增加量对于每个实施都是~Y ms。如果每个系统中的大多数测量误差是静止的，那么它们应该被消除。
In this test, X = 1000 ms and Y = 1000 ms.
在本试验中，X=1000 ms，Y=1000 ms。
The common parameters used for tests in this section are:
本节中用于测试的通用参数为：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Poisson sampling at lambda = 1 packet per second
o lambda=每秒1个数据包时的泊松采样
o Test duration = 900 seconds total (March 21, 2011)
o 测试持续时间=总共900秒（2011年3月21日）
The netem emulator was set to add constant delays as specified in the procedure above.
netem仿真器设置为添加上述过程中指定的恒定延迟。
Average pre-increase delay, microseconds 1089868.0 Average post 1 s additional, microseconds 2089686.0 Difference (should be ~= Y = 1 s) 999818.0
平均增加前延迟，微秒1089868.0平均增加1秒后，微秒2089686.0差异（应为~=Y=1s）999818.0
Average delays before/after 1 second increase
增加1秒之前/之后的平均延迟
The NetProbe implementation observed a 1 second increase with a 182 microsecond error (assuming that the netem emulated delay difference is exact).
NetProbe实现观察到1秒增加，误差为182微秒（假设netem模拟的延迟差是精确的）。
We note that this differential delay test has been run under lab conditions and published in prior work [ADV-METRICS]. The error was 6 microseconds.
我们注意到，此差异延迟测试已在实验室条件下运行，并在先前的工作[ADV-METRICS]中发布。错误为6微秒。
Average pre-increase delay, microseconds 1089794.0 Average post 1 s additional, microseconds 2089801.0 Difference (should be ~= Y = 1 s) 1000007.0
平均增加前延迟，微秒1089794.0平均增加1秒后，微秒2089801.0差异（应为~=Y=1s）100007.0
Average delays before/after 1 second increase
增加1秒之前/之后的平均延迟
The Perfas+ implementation observed a 1 second increase with a 7 microsecond error.
Perfas+实现观察到1秒的增长，并出现7微秒的错误。
Again, the live network conditions appear to have influenced the results, but both implementations measured the same delay increase within their calibration accuracy.
同样，实时网络条件似乎影响了结果，但两种实现在其校准精度范围内测量到相同的延迟增加。
The ADK tests the extent to which the sample distributions of one-way delay singletons from two implementations of [RFC2679] appear to be from the same overall distribution. By testing this way, we economize on the number of comparisons, because comparing a set of individual summary statistics (as defined in Section 5 of [RFC2679]) would require another set of individual evaluations of equivalence. Instead, we can simply check which statistics were implemented, and report on those facts, noting that Section 5 of [RFC2679] does not specify the calculations exactly, and gives only some illustrative examples.
ADK测试[RFC2679]的两个实现的单向延迟单例的样本分布在多大程度上似乎来自相同的总体分布。通过这种方式进行测试，我们节省了比较的次数，因为比较一组单独的汇总统计数据（如[RFC2679]第5节所定义）需要另一组单独的等效性评估。相反，我们可以简单地检查实施了哪些统计数据，并报告这些事实，注意到[RFC2679]的第5节没有准确地说明计算，只给出了一些示例。
NetProbe Perfas+
NetProbe性能+
5.1. Type-P-One-way-Delay-Percentile yes no
5.1. 类型-P-单向延迟-百分位是否
5.2. Type-P-One-way-Delay-Median yes no
5.2. 类型-P-单向延迟-中位数是否
5.3. Type-P-One-way-Delay-Minimum yes yes
5.3. 类型-P-单向延迟-最小值是是
5.4. Type-P-One-way-Delay-Inverse-Percentile no no
5.4. 类型-P-单向延迟-逆百分位编号
Implementation of Section 5 Statistics
第5款统计的执行情况
Only the Type-P-One-way-Delay-Inverse-Percentile has been ignored in both implementations, so it is a candidate for removal or deprecation in a revision of RFC 2679 (this small discrepancy does not affect candidacy for advancement).
在两种实施中，只有类型-P-单向延迟-反向百分位数被忽略，因此在RFC 2679修订版中，它是删除或弃用的候选项（这一微小差异不影响晋升候选资格）。
The conclusions throughout Section 6 support the advancement of [RFC2679] to the next step of the Standards Track, because its requirements are deemed to be clear and unambiguous based on evaluation of the test results for two implementations. The results indicate that these implementations produced statistically equivalent results under network conditions that were configured to be as close to identical as possible.
第6节中的结论支持将[RFC2679]推进到标准轨道的下一步，因为根据对两种实现的测试结果的评估，其要求被认为是明确的。结果表明，这些实现在配置为尽可能接近相同的网络条件下产生了统计上等效的结果。
Sections 6.2.3 and 6.5 indicate areas where minor revisions are warranted in RFC 2679. The IETF has reached consensus on guidance for reporting metrics in [RFC6703], and this memo should be referenced in the revision to RFC 2679 to incorporate recent experience where appropriate.
第6.2.3节和第6.5节指出了RFC 2679中允许进行小修改的领域。IETF已就[RFC6703]中的报告指标指南达成共识，本备忘录应在RFC 2679的修订版中引用，以在适当情况下纳入近期经验。
We note that there is currently one erratum with status "Held for Document Update" for [RFC2679], and it appears this minor revision and additional text should be incorporated in a revision of RFC 2679.
我们注意到，[RFC2679]目前有一个状态为“文件更新保留”的勘误表，看来这一次要修订和附加文本应纳入RFC 2679的修订版中。
The authors that revise [RFC2679] should review all errata filed at the time the document is being written. They should not rely upon this document to indicate all relevant errata updates.
修订[RFC2679]的作者应审查文件编写时提交的所有勘误表。他们不应依赖本文件说明所有相关勘误表更新。
The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357].
适用于实时网络的任何主动测量的安全注意事项也与此相关。参见[RFC4656]和[RFC5357]。
The authors thank Lars Eggert for his continued encouragement to advance the IPPM metrics during his tenure as AD Advisor.
作者感谢Lars Eggert在担任广告顾问期间不断鼓励推进IPPM指标。
Nicole Kowalski supplied the needed CPE router for the NetProbe side of the test setup, and graciously managed her testing in spite of issues caused by dual-use of the router. Thanks Nicole!
Nicole Kowalski为测试设置的NetProbe端提供了所需的CPE路由器，并亲切地管理了她的测试，尽管路由器的双重使用会导致问题。谢谢你，妮可！
The "NetProbe Team" also acknowledges many useful discussions with Ganga Maguluri.
“NetProbe团队”也承认与Ganga Maguluri进行了许多有益的讨论。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，1998年5月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，1999年9月。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002.
[RFC3432]Raisanen，V.，Grotefeld，G.，和A.Morton，“周期流的网络性能测量”，RFC 3432，2002年11月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zekauskas，“单向主动测量协议（OWAMP）”，RFC 46562006年9月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357]Hedayat，K.，Krzanowski，R.，Morton，A.，Yum，K.，和J.Babiarz，“双向主动测量协议（TWAMP）”，RFC 5357，2008年10月。
[RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
[RFC5657]Dusseault，L.和R.Sparks，“推进标准草案的互操作和实施报告指南”，BCP 9，RFC 5657，2009年9月。
[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, March 2012.
[RFC6576]Geib，R.，Morton，A.，Fardid，R.，和A.Steinmitz，“IP性能指标（IPPM）标准推进测试”，BCP 176，RFC 6576，2012年3月。
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, August 2012.
[RFC6703]Morton，A.，Ramachandran，G.，和G.Maguluri，“报告IP网络性能指标：不同观点”，RFC 67032012年8月。
[ADK] Scholz, F. and M. Stephens, "K-sample Anderson-Darling Tests of fit, for continuous and discrete cases", University of Washington, Technical Report No. 81, May 1986.
肖尔茨，F.和M. Stephens，“K样本Andersson亲爱的测试适合连续和离散病例”，华盛顿大学，技术报告第81号，1986年5月。
[ADV-METRICS] Morton, A., "Lab Test Results for Advancing Metrics on the Standards Track", Work in Progress, October 2010.
[ADV-METRICS]Morton，A.，“在标准轨道上推进指标的实验室测试结果”，进展中的工作，2010年10月。
[Fedora14] Fedora Project, "Fedora Project Home Page", 2012, <http://fedoraproject.org/>.
[Fedora14]Fedora项目，“Fedora项目主页”，2012年<http://fedoraproject.org/>.
[METRICS-TEST] Bradner, S. and V. Paxson, "Advancement of metrics specifications on the IETF Standards Track", Work in Progress, August 2007.
[METRICS-TEST]Bradner，S.和V.Paxson，“IETF标准轨道上的度量规范进展”，进展中的工作，2007年8月。
[Perfas] Heidemann, C., "Qualitaet in IP-Netzen Messverfahren", published by ITG Fachgruppe, 2nd meeting 5.2.3 (NGN), November 2001, <http://www.itg523.de/oeffentlich/01nov/ Heidemann_QOS_Messverfahren.pdf>.
[Perfas]Heidemann，C.，“IP Netzen Messwerfahren中的质量”，由ITG Fachgruppe出版，第2次会议5.2.3（NGN），2001年11月<http://www.itg523.de/oeffentlich/01nov/ Heidemann\u QOS\u Messverfahren.pdf>。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[Radk] Scholz, F., "adk: Anderson-Darling K-Sample Test and Combinations of Such Tests. R package version 1.0.", 2008.
[Radk]Scholz，F.，“adk:Anderson-Darling K样本测试及其组合。R软件包版本1.0.”，2008年。
[Rtool] R Development Core Team, "R: A language and environment for statistical computing. R Foundation for Statistical Computing, Vienna, Austria. ISBN 3-900051-07-0", 2011, <http://www.R-project.org/>.
[RToo] R发展核心团队，R：统计计算的语言和环境.R统计计算基础，奥地利维也纳，ISBN 3-900051-07- 0，2011，<http://www.R-project.org/>.
[WIPM] AT&T, "AT&T Global IP Network", 2012, <http://ipnetwork.bgtmo.ip.att.net/pws/index.html>.
[WIPM]AT&T，“AT&T全球IP网络”，2012年<http://ipnetwork.bgtmo.ip.att.net/pws/index.html>.
[netem] The Linux Foundation, "netem", 2009, <http://www.linuxfoundation.org/collaborate/workgroups/ networking/netem>.
[NETEM ] Linux基金会，“NETEM”，2009，<http://www.linuxfoundation.org/collaborate/workgroups/ 网络/netem>。
Authors' Addresses
作者地址
Len Ciavattone AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
美国新泽西州劳雷尔大道南米德尔顿200号Len Ciavattone AT&T实验室，邮编：07748
Phone: +1 732 420 1239
EMail: lencia@att.com
Phone: +1 732 420 1239
EMail: lencia@att.com
Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt, 64295 Germany
Ruediger Geib Deutsche Telekom Heinrich Hertz Str.3-7 Darmstadt，64295德国
Phone: +49 6151 58 12747
EMail: Ruediger.Geib@telekom.de
Phone: +49 6151 58 12747
EMail: Ruediger.Geib@telekom.de
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
美国新泽西州劳雷尔大道南米德尔顿200号阿尔莫顿AT&T实验室，邮编：07748
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Matthias Wieser Technical University Darmstadt Darmstadt, Germany
德国达姆施塔特市达姆施塔特市马蒂亚斯·维瑟技术大学
EMail: matthias_michael.wieser@stud.tu-darmstadt.de
EMail: matthias_michael.wieser@stud.tu-darmstadt.de