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
        
1. Introduction
1. 介绍

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修订版的批准留待将来采取行动。

1.1. Requirements Language
1.1. 需求语言

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]中使用了其中一些关键词,但本备忘录中没有规定要求。

1.2. RFC 2680 Coverage
1.2. 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节中至少发现了一个隐含要求的实例。

2. A Definition-Centric Metric Advancement Process
2. 以定义为中心的度量推进过程

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文本中体现的度量定义视为第一原则,即需要评估和可能修订的对象,以便进入标准轨道的下一步。本备忘录遵循这一过程。

3. Test Configuration
3. 测试配置

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隧道封装混淆)。

4. Error Calibration and RFC 2680
4. 误差校准和RFC2680

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节中报告成功到达目的地网络接口的数据包由于资源耗尽而被错误指定为丢失的概率。

4.1. Clock Synchronization Calibration
4.1. 时钟同步校准

For NetProbe and Perfas+ clock synchronization test results, refer to Section 4 of [RFC6808].

有关NetProbe和Perfas+时钟同步测试结果,请参阅[RFC6808]的第4节。

4.2. Packet Loss Determination Error
4.2. 丢包判定错误

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,平均分配给三个单播测试流。我们得出结论,稳定的资源使用不会对测量造成误差(额外损失)。

5. Predetermined Limits on Equivalence
5. 等价性的预定限制

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.

在本节中,我们