Internet Engineering Task Force (IETF) L. Ciavattone
Request for Comments: 7290 AT&T Labs
Category: Informational R. Geib
ISSN: 2070-1721 Deutsche Telekom
A. Morton
AT&T Labs
M. Wieser
Technical University Darmstadt
July 2014
Internet Engineering Task Force (IETF) L. Ciavattone
Request for Comments: 7290 AT&T Labs
Category: Informational R. Geib
ISSN: 2070-1721 Deutsche Telekom
A. Morton
AT&T Labs
M. Wieser
Technical University Darmstadt
July 2014
Test Plan and Results for Advancing RFC 2680 on the Standards Track
在标准轨道上推进RFC 2680的测试计划和结果
Abstract
摘要
This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. 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 2680.
本备忘录提供了支持性测试计划和结果，以促进RFC 2680的发展，RFC 2680是一种性能指标，定义了单向数据包丢失指标，并沿着标准轨道前进。注意到度量定义本身应该是主要焦点，而不是度量的实现，本备忘录描述了评估特定度量需求条款的测试程序，以确定需求是否按照预期进行了解释和实现。两个完全独立的实现已经根据RFC2680的关键规范进行了测试。
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/rfc7290.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7290.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束
(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.
(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 ......................................4
1.2. RFC 2680 Coverage ..........................................5
2. A Definition-Centric Metric Advancement Process .................5
3. Test Configuration ..............................................5
4. Error Calibration and RFC 2680 ..................................9
4.1. Clock Synchronization Calibration ..........................9
4.2. Packet Loss Determination Error ...........................10
5. Predetermined Limits on Equivalence ............................10
6. Tests to Evaluate RFC 2680 Specifications ......................11
6.1. One-Way Loss: ADK Sample Comparison .......................11
6.1.1. 340B/Periodic Cross-Implementation Results .........12
6.1.2. 64B/Periodic Cross-Implementation Results ..........14
6.1.3. 64B/Poisson Cross-Implementation Results ...........15
6.1.4. Conclusions on the ADK Results for One-Way
Packet Loss ........................................16
6.2. One-Way Loss: Delay Threshold .............................16
6.2.1. NetProbe Results for Loss Threshold ................17
6.2.2. Perfas+ Results for Loss Threshold .................17
6.2.3. Conclusions for Loss Threshold .....................17
6.3. One-Way Loss with Out-of-Order Arrival ....................17
6.4. Poisson Sending Process Evaluation ........................19
6.4.1. NetProbe Results ...................................19
6.4.2. Perfas+ Results ....................................20
6.4.3. Conclusions for Goodness-of-Fit ....................22
6.5. Implementation of Statistics for One-Way Loss .............23
7. Conclusions for a Revision of RFC 2680 .........................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Appendix - Network Configuration and Sample Commands ..........25
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................29
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. RFC 2680 Coverage ..........................................5
2. A Definition-Centric Metric Advancement Process .................5
3. Test Configuration ..............................................5
4. Error Calibration and RFC 2680 ..................................9
4.1. Clock Synchronization Calibration ..........................9
4.2. Packet Loss Determination Error ...........................10
5. Predetermined Limits on Equivalence ............................10
6. Tests to Evaluate RFC 2680 Specifications ......................11
6.1. One-Way Loss: ADK Sample Comparison .......................11
6.1.1. 340B/Periodic Cross-Implementation Results .........12
6.1.2. 64B/Periodic Cross-Implementation Results ..........14
6.1.3. 64B/Poisson Cross-Implementation Results ...........15
6.1.4. Conclusions on the ADK Results for One-Way
Packet Loss ........................................16
6.2. One-Way Loss: Delay Threshold .............................16
6.2.1. NetProbe Results for Loss Threshold ................17
6.2.2. Perfas+ Results for Loss Threshold .................17
6.2.3. Conclusions for Loss Threshold .....................17
6.3. One-Way Loss with Out-of-Order Arrival ....................17
6.4. Poisson Sending Process Evaluation ........................19
6.4.1. NetProbe Results ...................................19
6.4.2. Perfas+ Results ....................................20
6.4.3. Conclusions for Goodness-of-Fit ....................22
6.5. Implementation of Statistics for One-Way Loss .............23
7. Conclusions for a Revision of RFC 2680 .........................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Appendix - Network Configuration and Sample Commands ..........25
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................29
The IETF IP Performance Metrics (IPPM) working group has considered how to advance their metrics along the Standards Track since 2001.
自2001年以来，IETF IP性能度量（IPPM）工作组一直在考虑如何沿着标准轨道推进其度量。
The renewed work effort sought to investigate ways in which the measurement variability could be reduced in order to thereby simplify the problem of comparison for equivalence. As a result, there is consensus (captured in [RFC6576]) that equivalent results from independent implementations of metric specifications are sufficient evidence that the specifications themselves are clear and unambiguous; it is the parallel concept of protocol interoperability
新的工作努力试图研究减少测量可变性的方法，从而简化等效性比较问题。因此，一致认为（参见[RFC6576]）度量规范独立实现的等效结果足以证明规范本身是明确的；它是协议互操作性的并行概念
for metric specifications. The advancement process either (1) produces confidence that the metric definitions and supporting material are clearly worded and unambiguous or (2) identifies ways in which the metric definitions should be revised to achieve clarity. It is a non-goal to compare the specific implementations themselves.
对于公制规格。推进过程要么（1）产生信心，认为度量定义和支持材料措词明确，不含糊，要么（2）确定应修改度量定义以实现清晰性的方式。比较具体实现本身并不是目标。
The process also permits identification of options described in the metric RFC that were not implemented, so that they can be removed from the advancing specification (this is an aspect more typical of protocol advancement along the Standards Track).
该过程还允许识别度量RFC中描述的未实现的选项，以便可以将其从推进规范中删除（这是标准轨道上协议推进的一个更典型的方面）。
This memo's purpose is to implement the current approach for [RFC2680] and document the results.
本备忘录旨在实施[RFC2680]的当前方法，并记录结果。
In particular, this memo documents consensus on the extent of tolerable errors when assessing equivalence in the results. In discussions, the IPPM working group agreed that the test plan and procedures should include the threshold for determining equivalence, and this information should be available in advance of cross-implementation comparisons. This memo includes procedures for same-implementation comparisons to help set the equivalence threshold.
特别是，本备忘录记录了评估结果等效性时可容忍误差范围的共识。在讨论中，IPPM工作组一致认为，测试计划和程序应包括确定等效性的阈值，并且应在交叉实施比较之前提供该信息。此备忘录包括相同实现比较的过程，以帮助设置等效阈值。
Another aspect of the metric RFC advancement process is the requirement to document the work and results. The procedures of [RFC2026] are expanded in [RFC5657], including sample implementation and interoperability reports. This memo follows the template in [RFC6808] for the report that accompanies the protocol action request submitted to the Area Director, including a description of the test setup, procedures, results for each implementation, and conclusions.
公制RFC推进过程的另一个方面是记录工作和结果的要求。[RFC2026]的程序在[RFC5657]中进行了扩展，包括示例实现和互操作性报告。本备忘录遵循[RFC6808]中提交给区域主管的协议行动请求附带的报告模板，包括测试设置、程序、每次实施的结果和结论的说明。
The conclusion reached is that [RFC2680], with modifications, should be advanced on the Standards Track. The revised text of RFC 2680 [LOSS-METRIC] is ready for review but awaits work in progress to update the IPPM Framework [RFC2330]. Therefore, this memo documents the information to support the advancement of [RFC2680], and the approval of a revision of RFC 2680 is left for future action.
得出的结论是，[RFC2680]经过修改后，应在标准轨道上前进。RFC 2680[LOSS-METRIC]的修订文本已准备就绪，可供审查，但仍在等待IPPM框架[RFC2330]的更新工作。因此，本备忘录记录了支持推进[RFC2680]的信息，RFC 2680修订版的批准留待将来采取行动。
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]. Some of these key words were used in [RFC2680], but there are no requirements specified in this memo.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。[RFC2680]中使用了其中一些关键词，但本备忘录中没有规定要求。
This plan is intended to cover all critical requirements and sections of [RFC2680].
本计划旨在涵盖[RFC2680]的所有关键要求和章节。
Note that there are only five relevant instances of the requirement term "MUST" in [RFC2680], outside of the boilerplate and [RFC2119] reference; the instance of "MUST" in the Security Considerations section of [RFC2680] is not a basis for implementation equivalence comparisons.
注意，在[RFC2680]中，在样板文件和[RFC2119]参考文献之外，只有五个相关的需求术语“必须”实例；[RFC2680]的安全注意事项部分中的“必须”实例不是实现等价性比较的基础。
Statements in RFC 2680 that have the character of requirements may be included if the community reaches consensus that the wording implies a requirement. At least one instance of an implied requirement has been found in Section 3.6 of [RFC2680].
如果社区一致认为RFC 2680中的措辞暗示要求，则可以包含具有要求性质的声明。[RFC2680]第3.6节中至少发现了一个隐含要求的实例。
The process described in Section 3.5 of [RFC6576] takes as a first principle 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节中描述的过程将RFCs文本中体现的度量定义视为第一原则，即需要评估和可能修订的对象，以便进入标准轨道的下一步。本备忘录遵循这一过程。
One metric implementation used was NetProbe version 5.8.5 (an earlier version is used in the WIPM system and deployed worldwide [WIPM]). NetProbe uses UDP packets of variable size and can produce test streams with Periodic [RFC3432] or Poisson [RFC2330] sample distributions.
使用的一个度量实现是NetProbe版本5.8.5（WIPM系统中使用了早期版本，并在全球范围内部署[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) [RFC3931] tunnel IDs (1 and 2), based on Figure 1 of [RFC6576].
图1显示了基于[RFC6576]图1的每个实现的测试流通过Internet和第2层隧道协议版本3（L2TPv3）[RFC3931]隧道ID（1和2）时的测试路径视图。
+------------+ +------------+
| Imp 1 | ,---. | Imp 2 |
+------------+ / \ +-------+ +------------+
| 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
+------------+ +------------+
| Imp 1 | ,---. | Imp 2 |
+------------+ / \ +-------+ +------------+
| 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 (where "Imp #" is the sender and receiver of implementation 1 or 2 -- either Perfas+ or NetProbe in this test). The lower diagram shows example flows traveling between two measurement implementations. For simplicity, only two flows are shown, and the netem emulator is omitted (it would appear before or after the Internet, depending on the flow).
带有双向通道的测试设置图示。上图强调了VLAN连接和地理位置（其中“Imp#”是实现1或2的发送方和接收方——在本测试中为Perfas+或NetProbe）。下图显示了两个测量实现之间的示例流。为简单起见，只显示了两个流，并且省略了netem仿真器（它将显示在Internet之前或之后，具体取决于流）。
Figure 1
图1
The testing employs the 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.
测试采用互联网上测试站点之间的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 point of view of the test equipment.
在隧道的每一端，封装在隧道中的一对VLAN被环回，以便将测试流量返回到每个测试站点。因此，测试流穿过L2TP隧道两次，但从测试设备的角度来看，似乎是单向测试。
The network emulator is a host running Fedora 14 Linux [FEDORA], with IP forwarding enabled and the "netem" Network emulator as part of the Fedora Kernel 2.6.35.11 [NETEM] loaded and operating. The standard kernel is "tickless", replacing the previous periodic timer (250 Hz, with 4 ms uncertainty) interrupts with on-demand interrupts. 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 operated on test streams traveling in one direction. In some tests, independent netem instances operated separately on each VLAN. See the Appendix for more details.
网络仿真器是一台运行Fedora 14 Linux[Fedora]的主机，启用了IP转发功能，“netem”网络仿真器作为Fedora内核2.6.35.11[netem]的一部分加载并运行。标准内核是“无滴答”的，用按需中断取代以前的周期性定时器（250赫兹，不确定度为4毫秒）中断。通过桥接以太网VLAN接口和“brctl”命令（例如，eth1.100<->eth2.100），可实现netem/Fedora主机之间的连接。netem仿真器在一个接口（eth1）上激活，并且仅对沿一个方向移动的测试流进行操作。在一些测试中，独立的netem实例分别在每个VLAN上运行。有关更多详细信息，请参见附录。
The links between the netem emulator host, the router, and the switch were found to be 100BaseTX-HD (100 Mbps half duplex), as reported by "mii-tool" [MII-TOOL] when testing was complete. The 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.
测试完成时，“mii工具”[mii-tool]报告，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.
每个单独的测试都是以常见的数据包速率（1 pps、10 pps）泊松/周期分布和64、340和500字节的IP数据包大小运行的。
For these tests, a stream of at least 300 packets was 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]），除非另有说明。
As required in Section 2.8.1 of [RFC2680], packet Type-P must be reported. The packet Type-P for this test was IP-UDP with Best Effort Differentiated Services Code Point (DSCP). These headers were encapsulated according to the L2TPv3 specification [RFC3931] and were unlikely to influence the treatment received as the packets traversed the Internet.
按照[RFC2680]第2.8.1节的要求，必须报告数据包类型P。此测试的数据包类型P为IP-UDP，具有最大努力区分服务代码点（DSCP）。这些报头是根据L2TPv3规范[RFC3931]封装的，不太可能影响在数据包通过互联网时接收到的处理。
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-Packet-Loss-<StreamType>-Stream
Type-IP-protocol-115-One-way-Packet-Loss-<StreamType>-流
With (Section 3.2 of [RFC2680]) metric parameters:
（RFC2680第3.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 2.8.2 of [RFC2680])
+ Thresh，以秒为单位的最大等待时间（见[RFC2680]第2.8.2节）
Metric Units: A sequence of pairs; the elements of each pair are:
公制单位：成对的序列；每对的元素包括：
+ T, a time, and
+ T、 一次，和
+ L, either a zero or a one
+ 五十、 要么是零，要么是一
The values of T in the sequence are monotonically increasing. Note that T would be a valid parameter of *singleton* Type-P-One-way-Packet-Loss and that L would be a valid value of Type-P-One-way-Packet-Loss (see Section 3.3 of [RFC2680]).
序列中T的值是单调递增的。请注意，T将是*singleton*Type-P-One-way-Packet-Loss的有效参数，L将是Type-P-One-way-Packet-Loss的有效值（见[RFC2680]第3.3节）。
Also, Section 2.8.4 of [RFC2680] 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 traceroute can be conducted by the routers at each location.
此外，[RFC2680]第2.8.4节建议报告路径。在该测试设置中，大部分路径细节将被L2TPv3隧道隐藏；因此，路由器可以在每个位置执行更具信息性的路径跟踪路由。
When NetProbe is used in production, a traceroute is conducted in parallel 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***
NetProbe Traceroute
NetProbe跟踪路由
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 calibration results on clock synchronization per Section 2.8.3 of [RFC2680] (also required in Section 3.7 of [RFC2680] for sample metrics).
需要按照[RFC2680]第2.8.3节的要求报告时钟同步的校准结果（对于样本度量，[RFC2680]第3.7节也要求）。
Also, it is recommended to report the probability that a packet successfully arriving at the destination network interface is incorrectly designated as lost due to resource exhaustion in Section 2.8.3 of [RFC2680].
此外，建议在[RFC2680]第2.8.3节中报告成功到达目的地网络接口的数据包由于资源耗尽而被错误指定为丢失的概率。
For NetProbe and Perfas+ clock synchronization test results, refer to Section 4 of [RFC6808].
有关NetProbe和Perfas+时钟同步测试结果，请参阅[RFC6808]的第4节。
Since both measurement implementations have resource limitations, it is theoretically possible that these limits could be exceeded and a packet that arrived at the destination successfully might be discarded in error.
由于两种测量实现都有资源限制，理论上可能会超过这些限制，并且成功到达目的地的数据包可能会被错误地丢弃。
In previous test efforts [ADV-METRICS], NetProbe produced six multicast streams with an aggregate bit rate over 53 Mbit/s, in order to characterize the one-way capacity of an emulator based on NIST Net. Neither the emulator nor the pair of NetProbe implementations used in this testing dropped any packets in these streams.
在之前的测试工作[ADV-METRICS]中，NetProbe生成了六个聚合比特率超过53 Mbit/s的多播流，以表征基于NIST网络的仿真器的单向容量。此测试中使用的emulator和NetProbe实现对均未丢弃这些流中的任何数据包。
The maximum load used here between any two NetProbe implementations was 11.5 Mbit/s divided equally among three unicast test streams. We concluded that steady resource usage does not contribute error (additional loss) to the measurements.
此处在任何两个NetProbe实现之间使用的最大负载为11.5 Mbit/s，平均分配给三个单播测试流。我们得出结论，稳定的资源使用不会对测量造成误差（额外损失）。
In this section, we provide the numerical limits on comparisons between implementations in order to declare that the results are equivalent and that the tested specification is therefore clear.
在本节中，我们提供了实现之间比较的数值限制，以声明结果是等效的，因此测试规范是明确的。
A key point is that the allowable errors, corrections, and confidence levels only need to be sufficient to detect any misinterpretation of the tested specification that would indicate 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) [ADK] comparisons, the required confidence factor for the cross-implementation comparisons SHALL be the smallest of:
对于Anderson-Darling K样本（ADK）[ADK]比较，交叉实施比较所需的置信因子应为以下最小值：
o 0.95 confidence factor at 1-packet 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 (if the number of streams is sufficient to allow such comparisons).
o 相同测试条件下两个相同实现比较的最小置信因子（结合分辨率）（如果流的数量足以允许此类比较）。
For Anderson-Darling Goodness-of-Fit (ADGoF) [RADGOF] comparisons, the required level of significance for the same-implementation Goodness-of-Fit (GoF) SHALL be 0.05 or 5%, as specified in Section 11.4 of [RFC2330]. This is equivalent to a 95% confidence factor.
对于Anderson-Darling拟合优度（ADGoF）[RADGOF]比较，相同实施拟合优度（GoF）的要求显著性水平应为[RFC2330]第11.4节中规定的0.05或5%。这相当于95%的置信系数。
This section describes some results from production network (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 similar to those contained in Appendix A.1 of [RFC6576] for one-way delay.
该程序类似于[RFC6576]附录A.1中关于单向延迟的程序。
This test determines if implementations produce results that appear to come from a common packet loss distribution, as an overall evaluation of Section 3 of [RFC2680] ("A Definition for Samples of One-way Packet Loss"). Same-implementation comparison results help to set the threshold of equivalence that will be applied to cross-implementation comparisons.
作为[RFC2680]第3节（“单向丢包样本的定义”）的总体评估，该测试确定实施是否产生了来自常见丢包分布的结果。相同的实现比较结果有助于设置将应用于跨实现比较的等效阈值。
This test is intended to evaluate measurements in Sections 2, 3, and 4 of [RFC2680].
本试验旨在评估[RFC2680]第2、3和4节中的测量值。
By testing the extent to which the counts of one-way packet loss on different test streams of two [RFC2680] implementations appear to be from the same loss process, we reduce comparison steps because comparing the resulting summary statistics (as defined in Section 4 of [RFC2680]) would require a redundant set of equivalence evaluations. We can easily check whether the single statistic in Section 4 of [RFC2680] was implemented and report on that fact.
通过测试两个[RFC2680]实现的不同测试流上的单向数据包丢失计数在多大程度上似乎来自同一丢失过程，我们减少了比较步骤，因为比较得到的汇总统计数据（如[RFC2680]第4节所定义）需要一组冗余的等价性评估。我们可以很容易地检查[RFC2680]第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 a sample of one-way packet loss singletons with two or more implementations, using identical options and network emulator settings (if used).
2. 使用相同的选项和网络仿真器设置（如果使用），测量具有两个或多个实现的单向丢包单例示例。
3. Measure a sample of one-way packet loss singletons with *four or more* instances of the *same* implementations, using identical options, noting that connectivity differences SHOULD be the same as for cross-implementation testing.
3. 使用相同的选项测量具有*相同*实现的*四个或更多*实例的单向丢包单例样本，注意连接差异应与跨实现测试相同。
4. If less than ten test streams are available, skip to step 7.
4. 如果可用的测试流少于十个，则跳至步骤7。
5. Apply the ADK comparison procedures (see Appendix B of [RFC6576]), and determine the resolution and confidence factor for distribution equivalence of each same-implementation comparison and each cross-implementation comparison.
5. 应用ADK比较程序（见[RFC6576]附录B），并确定每个相同实施比较和每个交叉实施比较的分布等效性的分辨率和置信因子。
6. 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.
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 metric parameters varied for each loss test, and they are listed first in each sub-section below.
每个损耗测试的度量参数各不相同，下面各小节首先列出了这些参数。
The cross-implementation comparison uses a simple ADK analysis [RTOOL] [RADK], where all NetProbe loss counts are compared with all Perfas+ loss results.
交叉实现比较使用一个简单的ADK分析[RTOOL][RADK]，其中所有NetProbe损失计数与所有Perfas+损失结果进行比较。
In the results analysis of this section:
在本节的结果分析中：
o All comparisons used 1-packet resolution.
o 所有比较均使用1-数据包分辨率。
o No correction factors were applied.
o 未应用校正因子。
o The 0.95 confidence factor (and ADK criterion for t.obs < 1.960 for cross-implementation comparison) was used.
o 使用0.95置信因子（对于交叉实施比较，t.obs<1.960的ADK标准）。
Tests described in this section used:
本节所述的测试使用：
o IP header + payload = 340 octets
o IP头+有效负载=340个八位字节
o Periodic sampling at 1 packet per second
o 以每秒1包的速度进行定期采样
o Test duration = 1200 seconds (during April 7, 2011, EDT)
o 测试持续时间=1200秒（美国东部夏令时2011年4月7日）
The netem emulator was set for 100 ms constant delay, with a 10% loss ratio. 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 ms恒定延迟，损失率为10%。在本实验中，netem模拟器被配置为在每个VLAN上独立运行；因此，在比较沿不同方向穿过测试路径的流时，仿真器本身是一个潜在的错误源。
=======================================
=======================================
A07bps_loss <- c(114, 175, 138, 142, 181, 105) (NetProbe)
A07per_loss <- c(115, 128, 136, 127, 139, 138) (Perfas+)
A07bps_loss <- c(114, 175, 138, 142, 181, 105) (NetProbe)
A07per_loss <- c(115, 128, 136, 127, 139, 138) (Perfas+)
> A07bps_loss <- c(114, 175, 138, 142, 181, 105) > A07per_loss <- c(115, 128, 136, 127, 139, 138) > > A07cross_loss_ADK <- adk.test(A07bps_loss, A07per_loss) > A07cross_loss_ADK Anderson-Darling k-sample test.
>A07bps_损失<-c（114、175、138、142、181、105）>A07每_损失<-c（115、128、136、127、139、138）>>A07交叉损失ADK<-ADK.测试（A07bps_损失、A07每_损失）>A07交叉损失ADK-安德森-达林k样本测试。
Number of samples: 2 Sample sizes: 6 6 Total number of values: 12 Number of unique values: 11
样本数量：2样本大小：6总值数量：12唯一值数量：11
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.6569
Anderson-Darling标准的平均值：1 Anderson-Darling标准的标准偏差：0.6569
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.52043 0.20604 0 adj. for ties 0.62679 0.18607 0 >
t、 obs P值外推不调整。对于系带0.52043 0.20604 0调整。对于领带0.62679 0.18607 0>
=======================================
=======================================
The cross-implementation comparisons pass the ADK criterion (t.obs < 1.960).
交叉实现比较通过ADK标准（t.obs<1.960）。
Tests described in this section used:
本节所述的测试使用：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Periodic sampling at 1 packet per second
o 以每秒1包的速度进行定期采样
o Test duration = 300 seconds (during March 24, 2011, EDT)
o 测试持续时间=300秒（美国东部夏令时2011年3月24日）
The netem emulator was set for 0 ms constant delay, with a 10% loss ratio.
netem仿真器设置为0毫秒恒定延迟，损失率为10%。
=======================================
=======================================
> M24per_loss <- c(42,34,35,35) (Perfas+) > M24apd_23BC_loss <- c(27,39,29,24) (NetProbe) > M24apd_loss23BC_ADK <- adk.test(M24apd_23BC_loss,M24per_loss) > M24apd_loss23BC_ADK Anderson-Darling k-sample test.
>M24per_损失<-c（42,34,35,35）（Perfas+）>M24apd_23BC_损失<-c（27,39,29,24）（NetProbe）>M24apd_损失23BC_ADK<-ADK.测试（M24apd_23BC_损失，M24per_损失）>M24apd_损失23BC_ADK-样本测试。
Number of samples: 2 Sample sizes: 4 4 Total number of values: 8 Number of unique values: 7
样本数：2个样本大小：4个总值数：8个唯一值数：7
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.60978
Anderson-Darling标准的平均值：1 Anderson-Darling标准的标准偏差：0.60978
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.76921 0.16200 0 adj. for ties 0.90935 0.14113 0
t、 obs P值外推不调整。对于系带0.76921 0.16200 0调整。对于系带0.90935 0.14113 0
Warning: At least one sample size is less than 5. p-values may not be very accurate. >
警告：至少有一个样本大小小于5。p值可能不太准确。>
=======================================
=======================================
The cross-implementation comparisons pass the ADK criterion.
交叉实现比较通过ADK标准。
Tests described in this section used:
本节所述的测试使用：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Poisson sampling at lambda = 1 packet per second
o lambda=每秒1个数据包时的泊松采样
o Test duration = 1200 seconds (during April 27, 2011, EDT)
o 测试持续时间=1200秒（美国东部夏令时2011年4月27日）
The netem configuration was 0 ms delay and 10% loss, but there were two passes through an emulator for each stream, and loss emulation was present for 18 minutes of the 20-minute (1200-second) test.
netem配置为0毫秒延迟和10%损失，但每个流有两次通过模拟器，在20分钟（1200秒）的测试中，损失模拟持续18分钟。
=======================================
=======================================
A27aps_loss <- c(91,110,113,102,111,109,112,113) (NetProbe)
A27per_loss <- c(95,123,126,114) (Perfas+)
A27aps_loss <- c(91,110,113,102,111,109,112,113) (NetProbe)
A27per_loss <- c(95,123,126,114) (Perfas+)
A27cross_loss_ADK <- adk.test(A27aps_loss, A27per_loss)
A27交叉损耗ADK<-ADK.测试（A27aps损耗，A27per损耗）
> A27cross_loss_ADK Anderson-Darling k-sample test.
>A27交叉损失ADK安德森-达林k样试验。
Number of samples: 2 Sample sizes: 8 4 Total number of values: 12 Number of unique values: 11
样本数：2个样本大小：8 4总值数：12唯一值数：11
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.65642
Anderson-Darling标准的平均值：1 Anderson-Darling标准的标准偏差：0.65642
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 2.15099 0.04145 0 adj. for ties 1.93129 0.05125 0
t、 obs P值外推不调整。对于拉杆2.15099 0.04145 0调整。系材1.93129 0.05125 0
Warning: At least one sample size is less than 5. p-values may not be very accurate. >
警告：至少有一个样本大小小于5。p值可能不太准确。>
=======================================
=======================================
The cross-implementation comparisons barely pass the ADK criterion at 95% = 1.960 when adjusting for ties.
在调整关系时，交叉实现比较勉强通过ADK标准（95%=1.960）。
We conclude that the two implementations are capable of producing equivalent one-way packet loss measurements based on their interpretation of [RFC2680].
我们得出结论，这两种实现能够基于对[RFC2680]的解释产生等效的单向分组丢失测量。
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 Section 2.8.2 of [RFC2680].
见[RFC2680]第2.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 second of one-way constant delay in one direction of transmission.
2. 将网络模拟器配置为在一个传输方向上增加1秒的单向恒定延迟。
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 seconds of one-way constant delay in one direction of transmission equivalent to 2 seconds of additional one-way delay (or change the path delay while the 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 seconds of 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 EDT)
o 测试持续时间=总共900秒（美国东部夏令时2011年3月21日）
The netem emulator settings added constant delays as specified in the procedure above.
netem emulator设置添加了上述过程中指定的恒定延迟。
In NetProbe, the loss threshold was 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 were 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, which 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 [RFC2680]. This is a simple way to enforce the constant loss threshold envisioned in [RFC2680] (see Section 2.8.2 of [RFC2680]). We take the position that the assumption of post-processing is compliant and that the text of the revision of RFC 2680 should be revised slightly to include this point.
这两种实现都假设任何期望的恒定延迟值都可以用作损失阈值，因为所有延迟都按照[RFC2680]中的要求成对存储<Time，delay>。这是实施[RFC2680]中设想的恒定损耗阈值的简单方法（见[RFC2680]第2.8.2节）。我们的立场是，后处理的假设是符合的，RFC 2680修订版的文本应该稍微修改，以包括这一点。
Section 3.6 of [RFC2680] indicates, with a lowercase "must" in the text, that implementations need to ensure that reordered packets are handled correctly. In essence, this is an implied requirement because the correct packet must be identified as lost if it fails to arrive before its delay threshold under all circumstances, and reordering is always a possibility on IP network paths. See [RFC4737] for the definition of reordering used in IETF standard-compliant measurements.
[RFC2680]的第3.6节指出，文本中使用小写的“必须”，实现需要确保正确处理重新排序的数据包。本质上，这是一个隐含的要求，因为在所有情况下，如果正确的数据包未能在其延迟阈值之前到达，则必须将其标识为丢失，并且在IP网络路径上总是有可能重新排序。有关IETF标准兼容测量中使用的重新排序定义，请参见[RFC4737]。
The netem emulator can produce packet reordering because each packet's delay is drawn from an independent distribution. Here, significant delay (2000 ms) and delay variation (1000 ms) were
netem仿真器可以产生数据包重新排序，因为每个数据包的延迟都来自独立的分布。在这里，显著延迟（2000ms）和延迟变化（1000ms）被忽略
sufficient to produce packet reordering. Using the procedure described in Section 6.1, the netem emulator was set to introduce 10% loss while reordering was present.
足以产生数据包重新排序。使用第6.1节中描述的程序，netem仿真器被设置为在存在重新排序时引入10%的损失。
The tests described in this section used:
本节中所述的测试使用：
o IP header + payload = 64 octets
o IP头+有效负载=64个八位字节
o Periodic sampling = 1 packet per second
o 定期采样=每秒1个数据包
o Test duration = 600 seconds (during May 2, 2011, EDT)
o 测试持续时间=600秒（美国东部夏令时2011年5月2日）
=======================================
=======================================
> Y02aps_loss <- c(53,45,67,55) (NetProbe) > Y02per_loss <- c(59,62,67,69) (Perfas+) > Y02cross_loss_ADK <- adk.test(Y02aps_loss, Y02per_loss) > Y02cross_loss_ADK Anderson-Darling k-sample test.
>Y02aps_损失<-c（53,45,67,55）（NetProbe）>Y02 PER_损失<-c（59,62,67,69）（Perfas+）>Y02交叉损失ADK<-ADK.测试（Y02aps_损失，Y02 PER_损失）>Y02交叉损失ADK-安德森-达林k-样本测试。
Number of samples: 2 Sample sizes: 4 4 Total number of values: 8 Number of unique values: 7
样本数：2个样本大小：4个总值数：8个唯一值数：7
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.60978
Anderson-Darling标准的平均值：1 Anderson-Darling标准的标准偏差：0.60978
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 1.11282 0.11531 0 adj. for ties 1.19571 0.10616 0
t、 obs P值外推不调整。对于拉杆1.11282 0.11531 0调整。领带1.19571 0.10616 0
Warning: At least one sample size is less than 5. p-values may not be very accurate. >
警告：至少有一个样本大小小于5。p值可能不太准确。>
=======================================
=======================================
The test results indicate that extensive reordering was present. Both implementations capture the extensive delay variation between adjacent packets. In NetProbe, packet arrival order is preserved in the raw measurement files, so an examination of arrival packet sequence numbers also reveals reordering.
测试结果表明存在广泛的重新排序。两种实现都捕获相邻数据包之间的大量延迟变化。在NetProbe中，数据包到达顺序保留在原始测量文件中，因此对到达数据包序列号的检查也会显示重新排序。
Despite extensive continuous packet reordering present in the transmission path, the distributions of loss counts from the two implementations pass the ADK criterion at 95% = 1.960.
尽管传输路径中存在广泛的连续分组重新排序，但来自两个实现的丢失计数的分布在95%=1.960时通过ADK标准。
Section 3.7 of [RFC2680] indicates that implementations need to ensure that their sending process is reasonably close to a classic Poisson distribution when used. Much more detail on sample distribution generation and Goodness-of-Fit testing is specified in Section 11.4 of [RFC2330] and the Appendix of [RFC2330].
[RFC2680]第3.7节指出，实现需要确保其发送过程在使用时合理接近经典泊松分布。[RFC2330]第11.4节和[RFC2330]附录中详细说明了样本分布生成和拟合优度测试。
In this section, each implementation's Poisson distribution is compared with an idealistic version of the distribution available in the base functionality of the R-tool for Statistical Analysis [RTOOL] and performed using the Anderson-Darling Goodness-of-Fit test package (ADGofTest) [RADGOF]. The Goodness-of-Fit criterion derived from [RFC2330] requires a test statistic value AD <= 2.492 for 5% significance. The Appendix of [RFC2330] also notes that there may be difficulty satisfying the ADGofTest when the sample includes many packets (when 8192 were used, the test always failed, but smaller sets of the stream passed).
在本节中，将每个实现的泊松分布与R-tool for Statistic Analysis[RTOOL]基本功能中可用的理想分布版本进行比较，并使用Anderson-Darling拟合优度测试包（ADGofTest）[RADGOF]执行。根据[RFC2330]得出的拟合优度标准要求5%显著性的检验统计值AD<=2.492。[RFC2330]的附录还指出，当样本包括许多数据包时，可能难以满足ADGofTest（当使用8192时，测试总是失败，但通过的流集较小）。
Both implementations were configured to produce Poisson distributions with lambda = 1 packet per second and to assign received packet timestamps in the measurement application (above the UDP layer; see the calibration results in Section 4 of [RFC6808] for error assessment).
两种实现均配置为产生泊松分布，lambda=每秒1个数据包，并在测量应用程序中分配接收到的数据包时间戳（UDP层上方；错误评估见[RFC6808]第4节中的校准结果）。
Section 11.4 of [RFC2330] suggests three possible measurement points to evaluate the Poisson distribution. The NetProbe analysis uses "user-level timestamps made just before or after the system call for transmitting the packet".
[RFC2330]第11.4节建议了三个可能的测量点来评估泊松分布。NetProbe分析使用“在传输数据包的系统调用之前或之后制作的用户级时间戳”。
The statistical summary for two NetProbe streams is below:
两个NetProbe流的统计摘要如下：
=======================================
=======================================
> summary(a27ms$s1[2:1152]) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.0100 0.2900 0.6600 0.9846 1.3800 8.6390 > summary(a27ms$s2[2:1152]) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.010 0.280 0.670 0.979 1.365 8.829
>汇总表（a27ms$s1[2:1152]）最小第一季度中位平均第三季度最大值0.0100.2900.6600.9846 1.3800 8.6390>汇总表（a27ms$s2[2:1152]）最小第一季度中位平均第三季度最大值0.010 0.280 0.670.979 1.365 8.829
=======================================
=======================================
We see that both of the means are near the specified lambda = 1.
我们看到这两个平均值都接近指定的λ=1。
The results of ADGoF tests for these two streams are shown below:
这两个流的ADGoF测试结果如下所示：
=======================================
=======================================
> ad.test( a27ms$s1[2:101], pexp, 1)
> ad.test( a27ms$s1[2:101], pexp, 1)
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27ms$s1[2:101] and pexp
AD = 0.8908, p-value = 0.4197
alternative hypothesis: NA
data: a27ms$s1[2:101] and pexp
AD = 0.8908, p-value = 0.4197
alternative hypothesis: NA
> ad.test( a27ms$s1[2:1001], pexp, 1)
> ad.test( a27ms$s1[2:1001], pexp, 1)
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27ms$s1[2:1001] and pexp
AD = 0.9284, p-value = 0.3971
alternative hypothesis: NA
data: a27ms$s1[2:1001] and pexp
AD = 0.9284, p-value = 0.3971
alternative hypothesis: NA
> ad.test( a27ms$s2[2:101], pexp, 1)
> ad.test( a27ms$s2[2:101], pexp, 1)
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27ms$s2[2:101] and pexp
AD = 0.3597, p-value = 0.8873
alternative hypothesis: NA
data: a27ms$s2[2:101] and pexp
AD = 0.3597, p-value = 0.8873
alternative hypothesis: NA
> ad.test( a27ms$s2[2:1001], pexp, 1)
> ad.test( a27ms$s2[2:1001], pexp, 1)
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27ms$s2[2:1001] and pexp
AD = 0.6913, p-value = 0.5661
alternative hypothesis: NA
data: a27ms$s2[2:1001] and pexp
AD = 0.6913, p-value = 0.5661
alternative hypothesis: NA
=======================================
=======================================
We see that both sets of 100 packets and 1000 packets from two different streams (s1 and s2) all passed the AD <= 2.492 criterion.
我们看到，来自两个不同流（s1和s2）的100个包和1000个包的两组都通过了AD<=2.492标准。
Section 11.4 of [RFC2330] suggests three possible measurement points to evaluate the Poisson distribution. The Perfas+ analysis uses "wire times for the packets as recorded using a packet filter".
[RFC2330]第11.4节建议了三个可能的测量点来评估泊松分布。Perfas+分析使用“使用数据包过滤器记录的数据包的连线时间”。
However, due to limited access at the Perfas+ side of the test setup, the captures were made after the Perfas+ streams traversed the production network, adding a small amount of unwanted delay variation to the wire times (and possibly error due to packet loss).
但是，由于测试设置的Perfas+端的访问受限，捕获是在Perfas+流穿过生产网络之后进行的，这会给连线时间增加少量不必要的延迟变化（可能是由于数据包丢失而导致的错误）。
The statistical summary for two Perfas+ streams is below:
两个Perfas+流的统计摘要如下：
=======================================
=======================================
> summary(a27pe$p1) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.004 0.347 0.788 1.054 1.548 4.231 > summary(a27pe$p2) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.0010 0.2710 0.7080 0.9696 1.3740 7.1160
>汇总表（a27pe$p1）最小第一季度中值平均第三季度最大值0.004 0.347 0.788 1.054 1.548 4.231>汇总表（a27pe$p2）最小第一季度中值平均第三季度最大值0.0010 0.2710.7080 0.9696 1.3740 7.1160
=======================================
=======================================
We see that both of the means are near the specified lambda = 1.
我们看到这两个平均值都接近指定的λ=1。
The results of ADGoF tests for these two streams are shown below:
这两个流的ADGoF测试结果如下所示：
=======================================
=======================================
> ad.test(a27pe$p1, pexp, 1 )
>广告测试（a27pe$p1，pexp，1）
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27pe$p1 and pexp AD = 1.1364, p-value = 0.2930 alternative hypothesis: NA
数据：a27pe$p1和pexp AD=1.1364，p值=0.2930替代假设：NA
> ad.test(a27pe$p2, pexp, 1 )
>广告测试（a27pe$p2，pexp，1）
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27pe$p2 and pexp AD = 0.5041, p-value = 0.7424 alternative hypothesis: NA
数据：a27pe$p2和pexp AD=0.5041，p值=0.7424替代假设：NA
> ad.test(a27pe$p1[1:100], pexp, 1 )
> ad.test(a27pe$p1[1:100], pexp, 1 )
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27pe$p1[1:100] and pexp
AD = 0.7202, p-value = 0.5419
alternative hypothesis: NA
data: a27pe$p1[1:100] and pexp
AD = 0.7202, p-value = 0.5419
alternative hypothesis: NA
> ad.test(a27pe$p1[101:193], pexp, 1 )
> ad.test(a27pe$p1[101:193], pexp, 1 )
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27pe$p1[101:193] and pexp
AD = 1.4046, p-value = 0.201
alternative hypothesis: NA
data: a27pe$p1[101:193] and pexp
AD = 1.4046, p-value = 0.201
alternative hypothesis: NA
> ad.test(a27pe$p2[1:100], pexp, 1 )
> ad.test(a27pe$p2[1:100], pexp, 1 )
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27pe$p2[1:100] and pexp
AD = 0.4758, p-value = 0.7712
alternative hypothesis: NA
data: a27pe$p2[1:100] and pexp
AD = 0.4758, p-value = 0.7712
alternative hypothesis: NA
> ad.test(a27pe$p2[101:193], pexp, 1 )
> ad.test(a27pe$p2[101:193], pexp, 1 )
Anderson-Darling GoF Test
安德森-达林GoF试验
data: a27pe$p2[101:193] and pexp
AD = 0.3381, p-value = 0.9068
alternative hypothesis: NA
data: a27pe$p2[101:193] and pexp
AD = 0.3381, p-value = 0.9068
alternative hypothesis: NA
>
>
=======================================
=======================================
We see that sets of 193, 100, and 93 packets from two different streams (p1 and p2) all passed the AD <= 2.492 criterion.
我们看到来自两个不同流（p1和p2）的193、100和93个数据包的集合都通过了AD<=2.492标准。
Both NetProbe and Perfas+ implementations produce adequate Poisson distributions according to the Anderson-Darling Goodness-of-Fit at the 5% significance (1-alpha = 0.05, or 95% confidence level).
NetProbe和Perfas+实现都根据Anderson-Darling拟合优度在5%显著性（1-alpha=0.05，或95%置信水平）下产生足够的泊松分布。
We check to see which statistics were implemented and report on those facts, noting that Section 4 of [RFC2680] does not specify the calculations exactly and only gives some illustrative examples.
我们检查实施了哪些统计数据，并报告了这些事实，注意到[RFC2680]第4节没有准确说明计算，只给出了一些示例。
NetProbe Perfas+
NetProbe性能+
Type-P-One-way-Packet-Loss-Average yes yes (this is more commonly referred to as "loss ratio")
类型-P-单向-数据包丢失-平均是是是（这通常被称为“丢失率”）
Implementation of RFC 2680 Section 4 Statistics
RFC 2680第4节统计的实施
We note that implementations refer to this metric as a loss ratio, and this is an area for likely revision of the text to make it more consistent with widespread usage.
我们注意到，实现将此指标称为损失率，这是可能对文本进行修订以使其更符合广泛使用的一个方面。
This memo concludes that [RFC2680] should be advanced on the Standards Track and recommends the following edits to improve the text (which are not deemed significant enough to affect maturity).
本备忘录的结论是[RFC2680]应在标准轨道上推进，并建议进行以下编辑以改进文本（这些内容被认为不足以影响成熟度）。
o Revise Type-P-One-way-Packet-Loss-Ave to Type-P-One-way-Delay-Packet-Loss-Ratio.
o 将Type-P-One-way-Packet-Loss-Ave修改为Type-P-One-way-Delay-Packet-Loss-Ratio。
o Regarding implementation of the loss delay threshold (Section 6.2), the assumption of post-processing is compliant, and the text of the revision of RFC 2680 should be revised slightly to include this point.
o 关于损失延迟阈值的实施（第6.2节），后处理的假设是符合的，RFC 2680修订版的文本应稍作修改，以包括这一点。
o The IETF has reached consensus on guidance for reporting metrics [RFC6703], and this memo should be referenced in a revision of RFC 2680 to incorporate recent experience where appropriate.
o IETF已就报告指标指南[RFC6703]达成共识，本备忘录应在RFC 2680的修订版中引用，以在适当情况下纳入近期经验。
We note that there are at least two errata for [RFC2680], and it appears that these minor revisions should be incorporated in a revision of RFC 2680.
我们注意到，[RFC2680]至少有两个勘误表，这些次要修订似乎应纳入RFC 2680的修订中。
The authors that revise [RFC2680] 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.
The authors that revise [RFC2680] 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.translate error, please retry
We recognize the existence of BCP 170 [RFC6390], which provides guidelines for development of documents describing new performance metrics. However, the advancement of [RFC2680] represents fine-tuning of long-standing specifications based on experience that
我们认识到BCP 170[RFC6390]的存在，它为描述新性能指标的文档的开发提供了指导。然而，[RFC2680]的进步代表了基于以下经验的长期规范的微调：
helped to formulate BCP 170, and material that satisfies some of the requirements of [RFC6390] can be found in other RFCs, such as the IPPM Framework [RFC2330]. Thus, no specific changes to address BCP 170 guidelines are recommended for a revision of RFC 2680.
有助于制定BCP 170，满足[RFC6390]某些要求的材料可在其他RFC中找到，如IPPM框架[RFC2330]。因此，对于RFC 2680的修订，不建议对BCP 170指南进行具体修改。
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 Customer Premises Equipment (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 on statistical interpretation with Ganga Maguluri.
“NetProbe团队”还承认与Ganga Maguluri就统计解释进行了许多有益的讨论。
Constructive comments and helpful reviews were also provided by Bill Cerveny, Joachim Fabini, and Ann Cerveny.
Bill Cerveny、Joachim Fabini和Ann Cerveny也提供了建设性的评论和有益的评论。
This Appendix provides some background information on the host configuration and sample tc commands for the "netem" network emulator, as described in Section 3 and Figure 1 of this memo. These details are also applicable to the test plan in [RFC6808].
如本备忘录第3节和图1所述，本附录提供了“netem”网络仿真器的主机配置和示例tc命令的一些背景信息。这些细节也适用于[RFC6808]中的测试计划。
The host interface and configuration are shown below. Due to the limit of 72 characters per line, line breaks were added to the "tc" commands in the output below.
主机接口和配置如下所示。由于每行72个字符的限制，以下输出中的“tc”命令中添加了换行符。
[system@dell4-4 ~]$ su
Password:
[root@dell4-4 system]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
[root@dell4-4 system]# service iptables stop
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: nat filter [ OK ]
iptables: Unloading modules: [ OK ]
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
[root@dell4-4 system]# ifconfig eth1.300 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth1.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.300 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br300
[root@dell4-4 system]# brctl addif br300 eth1.300
[root@dell4-4 system]# brctl addif br300 eth2.300
[root@dell4-4 system]# ifconfig br300 up
[root@dell4-4 system]# brctl addbr br400
[root@dell4-4 system]# brctl addif br400 eth1.400
[root@dell4-4 system]# brctl addif br400 eth2.400
[root@dell4-4 system]# ifconfig br400 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[system@dell4-4 ~]$ su
Password:
[root@dell4-4 system]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
[root@dell4-4 system]# service iptables stop
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: nat filter [ OK ]
iptables: Unloading modules: [ OK ]
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
[root@dell4-4 system]# ifconfig eth1.300 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth1.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.300 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br300
[root@dell4-4 system]# brctl addif br300 eth1.300
[root@dell4-4 system]# brctl addif br300 eth2.300
[root@dell4-4 system]# ifconfig br300 up
[root@dell4-4 system]# brctl addbr br400
[root@dell4-4 system]# brctl addif br400 eth1.400
[root@dell4-4 system]# brctl addif br400 eth2.400
[root@dell4-4 system]# ifconfig br400 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[root@dell4-4 system]# brctl showmacs br300
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:02:b3:c4:c9:7a no 0.52
2 00:02:b3:cf:02:c6 no 0.52
2 00:0b:5f:54:de:81 no 0.01
[root@dell4-4 system]# brctl showmacs br400
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:02:b3:c4:c9:7a no 0.60
1 00:02:b3:cf:02:c6 no 0.42
2 00:0b:5f:54:de:81 no 0.33
[root@dell4-4 system]# tc qdisc add dev eth1.300 root netem
delay 100ms
[root@dell4-4 system]# brctl showmacs br300
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:02:b3:c4:c9:7a no 0.52
2 00:02:b3:cf:02:c6 no 0.52
2 00:0b:5f:54:de:81 no 0.01
[root@dell4-4 system]# brctl showmacs br400
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:02:b3:c4:c9:7a no 0.60
1 00:02:b3:cf:02:c6 no 0.42
2 00:0b:5f:54:de:81 no 0.33
[root@dell4-4 system]# tc qdisc add dev eth1.300 root netem
delay 100ms
[root@dell4-4 system]# ifconfig eth1.200 0.0.0.0 promisc up
[root@dell4-4 system]# vconfig add eth1 100
Added VLAN with VID == 100 to IF -:eth1:-
[root@dell4-4 system]# ifconfig eth1.200 0.0.0.0 promisc up
[root@dell4-4 system]# vconfig add eth1 100
Added VLAN with VID == 100 to IF -:eth1:-
[root@dell4-4 system]# ifconfig eth1.100 0.0.0.0 promisc up
[root@dell4-4系统]#ifconfig eth1.100 0.0.0.0 promisc up
[root@dell4-4 system]# vconfig add eth2 100
Added VLAN with VID == 100 to IF -:eth2:-
[root@dell4-4 system]# vconfig add eth2 100
Added VLAN with VID == 100 to IF -:eth2:-
[root@dell4-4 system]# ifconfig eth2.100 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.200 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br100
[root@dell4-4 system]# brctl addif br100 eth1.100
[root@dell4-4 system]# brctl addif br100 eth2.100
[root@dell4-4 system]# ifconfig br100 up
[root@dell4-4 system]# brctl addbr br200
[root@dell4-4 system]# brctl addif br200 eth1.200
[root@dell4-4 system]# brctl addif br200 eth2.200
[root@dell4-4 system]# ifconfig br200 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br100 8000.0002b3109b8a no eth1.100
eth2.100
br200 8000.0002b3109b8a no eth1.200
eth2.200
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[root@dell4-4 system]# ifconfig eth2.100 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.200 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br100
[root@dell4-4 system]# brctl addif br100 eth1.100
[root@dell4-4 system]# brctl addif br100 eth2.100
[root@dell4-4 system]# ifconfig br100 up
[root@dell4-4 system]# brctl addbr br200
[root@dell4-4 system]# brctl addif br200 eth1.200
[root@dell4-4 system]# brctl addif br200 eth2.200
[root@dell4-4 system]# ifconfig br200 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br100 8000.0002b3109b8a no eth1.100
eth2.100
br200 8000.0002b3109b8a no eth1.200
eth2.200
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[root@dell4-4 system]# brctl showmacs br100
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:0a:e4:83:89:07 no 0.19
2 00:0b:5f:54:de:81 no 0.91
2 00:e0:ed:0f:72:86 no 1.28
[root@dell4-4 system]# brctl showmacs br200
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:0a:e4:83:89:07 no 1.14
2 00:0b:5f:54:de:81 no 1.87
1 00:e0:ed:0f:72:86 no 0.24
[root@dell4-4 system]# tc qdisc add dev eth1.100 root netem
delay 100ms
[root@dell4-4 system]#
[root@dell4-4 system]# brctl showmacs br100
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:0a:e4:83:89:07 no 0.19
2 00:0b:5f:54:de:81 no 0.91
2 00:e0:ed:0f:72:86 no 1.28
[root@dell4-4 system]# brctl showmacs br200
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:0a:e4:83:89:07 no 1.14
2 00:0b:5f:54:de:81 no 1.87
1 00:e0:ed:0f:72:86 no 0.24
[root@dell4-4 system]# tc qdisc add dev eth1.100 root netem
delay 100ms
[root@dell4-4 system]#
=====================================================================
=====================================================================
Some sample tc command lines controlling netem and its impairments are given below.
下面给出了一些控制netem及其损害的tc命令行示例。
tc qdisc add dev eth1.100 root netem loss 0% tc qdisc add dev eth1.200 root netem loss 0% tc qdisc add dev eth1.300 root netem loss 0% tc qdisc add dev eth1.400 root netem loss 0%
tc qdisc添加开发eth1.100根网络损耗0%tc qdisc添加开发eth1.200根网络损耗0%tc qdisc添加开发eth1.300根网络损耗0%tc qdisc添加开发eth1.400根网络损耗0%
Add delay and delay variation: tc qdisc change dev eth1.100 root netem delay 100ms 50ms tc qdisc change dev eth1.200 root netem delay 100ms 50ms tc qdisc change dev eth1.300 root netem delay 100ms 50ms tc qdisc change dev eth1.400 root netem delay 100ms 50ms
添加延迟和延迟变化：tc qdisc更改开发eth1.100根网络延迟100ms 50ms tc qdisc更改开发eth1.200根网络延迟100ms 50ms tc qdisc更改开发eth1.300根网络延迟100ms 50ms tc qdisc更改开发eth1.400根网络延迟100ms 50ms
Add delay, delay variation, and loss: tc qdisc change dev eth1 root netem delay 2000ms 1000ms loss 10%
添加延迟、延迟变化和损失：tc qdisc更改开发eth1根网络延迟2000ms 1000ms损失10%
=====================================================================
=====================================================================
[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月。
[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月。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[RFC4737]Morton，A.，Ciavattone，L.，Ramachandran，G.，Shalunov，S.，和J.Perser，“数据包重新排序度量”，RFC 4737，2006年11月。
[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月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390]Clark，A.和B.Claise，“考虑新性能指标开发的指南”，BCP 170，RFC 63902011年10月。
[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月。
[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track", RFC 6808, December 2012.
[RFC6808]Ciavattone，L.，Geib，R.，Morton，A.，和M.Wieser，“支持在标准轨道上推进RFC 2679的测试计划和结果”，RFC 68082012年12月。
[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月。
[FEDORA] "Fedora", <http://fedoraproject.org/>.
[软呢帽]“软呢帽”<http://fedoraproject.org/>.
[LOSS-METRIC] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IPPM", Work in Progress, July 2014.
[LOSS-METRIC]Almes，G.，Kalidini，S.，Zekauskas，M.，和A.Morton，Ed.，“IPPM的单向损失指标”，在建工程，2014年7月。
[MII-TOOL] Hinds, D., Becker, D., and B. Eckenfels, "Linux System Administrator's Manual", February 2013, <http://man7.org/linux/man-pages/man8/mii-tool.8.html>.
[MII-TOOL]Hinds，D.，Becker，D.，和B.Eckenfels，“Linux系统管理员手册”，2013年2月<http://man7.org/linux/man-pages/man8/mii-tool.8.html>.
[NETEM] Linux Foundation, "netem", <http://www.linuxfoundation.org/collaborate/workgroups/ networking/netem>.
[NETEM ] Linux基金会，“NETEM”，<http://www.linuxfoundation.org/collaborate/workgroups/ 网络/netem>。
[Perfas] Heidemann, C., "Qualitaet in IP-Netzen Messverfahren", published by ITG Fachgruppe, 2nd meeting 5.2.3, November 2001, <www.itg523.de/oeffentlich/01nov/ Heidemann_QOS_Messverfahren.pdf>.
[Perfas]Heidemann，C.，“IP网络服务质量”，由ITG Fachgruppe出版，第2次会议5.2.3，2001年11月，<www.itg523.de/oeffentlich/011nov/Heidemann_QOS_Messverfahren.pdf>。
[RADGOF] Bellosta, C., "ADGofTest: Anderson-Darling Goodness-of-Fit Test. R package version 0.3.", R-Package Version 0.3, December 2011, <http://cran.r-project.org/web/packages/ ADGofTest/index.html>.
[RADGOF]Bellosta，C.，“ADGofTest:Anderson-Darling拟合优度测试.R软件包版本0.3.”，R软件包版本0.3，2011年12月<http://cran.r-project.org/web/packages/ ADGofTest/index.html>。
[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年。
[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月。
[RTOOL] R Development Core Team, "R: A Language and Environment for Statistical Computing", ISBN 3-900051-07-0, 2014, <http://www.R-project.org/>.
[RTOOL]R开发核心团队，“R:统计计算语言和环境”，ISBN 3-900051-07-02014<http://www.R-project.org/>.
[WIPM] AT&T, "AT&T Global IP Network", 2014, <http://ipnetwork.bgtmo.ip.att.net/pws/index.html>.
[WIPM]AT&T，“AT&T全球IP网络”，2014年<http://ipnetwork.bgtmo.ip.att.net/pws/index.html>.
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