Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 6673 AT&T Labs
Category: Standards Track August 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 6673 AT&T Labs
Category: Standards Track August 2012
ISSN: 2070-1721
Round-Trip Packet Loss Metrics
往返数据包丢失度量
Abstract
摘要
Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.
许多用户应用程序（以及使其成为可能的传输协议）需要双向通信。为了评估这种能力，并实现测试系统的简单性，在实践中经常进行往返损耗测量。RFC 5357中规定的双向主动测量协议为互联网建立了往返损耗测量能力。然而，目前没有根据RFC 2330框架指定往返分组丢失度量。
This memo adds round-trip loss to the set of IP Performance Metrics (IPPM).
此备忘录将往返损失添加到IP性能指标（IPPM）集合中。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6673.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6673.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Motivation .................................................4
1.2. Requirements Language ......................................5
2. Scope ...........................................................5
3. Common Specifications for Round-Trip Metrics ....................5
3.1. Name: Type-P-* .............................................5
3.2. Metric Parameters ..........................................5
3.3. Metric Definition ..........................................6
3.4. Metric Units ...............................................6
4. A Singleton Round-Trip Loss Metric ..............................7
4.1. Name: Type-P-Round-trip-Loss ...............................7
4.2. Metric Parameters ..........................................7
4.3. Definition and Metric Units ................................7
4.4. Discussion and Other Details ...............................8
5. A Sample Round-Trip Loss Metric .................................9
5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream ...............9
5.2. Metric Parameters ..........................................9
5.3. Definition and Metric Units ................................9
5.4. Discussion and Other Details ..............................10
6. Round-Trip Loss Statistic ......................................10
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio .....................10
7. Round-Trip Testing and One-Way Reporting .......................11
8. Measurement Considerations and Calibration .....................11
9. Security Considerations ........................................12
9.1. Denial-of-Service Attacks .................................12
9.2. User Data Confidentiality .................................12
9.3. Interference with the Metrics .............................12
10. IANA Considerations ...........................................13
11. Acknowledgements ..............................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
1. Introduction ....................................................3
1.1. Motivation .................................................4
1.2. Requirements Language ......................................5
2. Scope ...........................................................5
3. Common Specifications for Round-Trip Metrics ....................5
3.1. Name: Type-P-* .............................................5
3.2. Metric Parameters ..........................................5
3.3. Metric Definition ..........................................6
3.4. Metric Units ...............................................6
4. A Singleton Round-Trip Loss Metric ..............................7
4.1. Name: Type-P-Round-trip-Loss ...............................7
4.2. Metric Parameters ..........................................7
4.3. Definition and Metric Units ................................7
4.4. Discussion and Other Details ...............................8
5. A Sample Round-Trip Loss Metric .................................9
5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream ...............9
5.2. Metric Parameters ..........................................9
5.3. Definition and Metric Units ................................9
5.4. Discussion and Other Details ..............................10
6. Round-Trip Loss Statistic ......................................10
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio .....................10
7. Round-Trip Testing and One-Way Reporting .......................11
8. Measurement Considerations and Calibration .....................11
9. Security Considerations ........................................12
9.1. Denial-of-Service Attacks .................................12
9.2. User Data Confidentiality .................................12
9.3. Interference with the Metrics .............................12
10. IANA Considerations ...........................................13
11. Acknowledgements ..............................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
This memo defines a metric to quantify an IP network's ability to transfer packets in both directions from one host to another host. Two-way communication is almost always needed; thus, failure to transfer a packet in either direction constitutes a round-trip packet loss.
此备忘录定义了一个指标，用于量化IP网络从一台主机向另一台主机双向传输数据包的能力。几乎总是需要双向沟通；因此，未能在任一方向上传输分组构成往返分组丢失。
This memo defines a metric for round-trip packet loss on Internet paths. It builds on the notions and conventions introduced in the IP Performance Metrics (IPPM) framework [RFC2330]. Also, the specifications of the one-way packet loss metric for IPPM [RFC2680] and the round-trip delay metric for IPPM [RFC2681] are frequently
此备忘录定义了Internet路径上往返数据包丢失的度量。它基于IP性能度量（IPPM）框架[RFC2330]中引入的概念和约定。此外，IPPM[RFC2680]的单向分组丢失度量和IPPM[RFC2681]的往返延迟度量的规范经常被忽略
referenced and modified to match the round-trip circumstances addressed here. However, this memo assumes that the reader is familiar with the references; thus, it does not repeat material as was done in [RFC2681].
参考并修改以匹配此处所述的往返情况。然而，本备忘录假定读者熟悉参考资料；因此，它不会重复[RFC2681]中所述的材料。
This memo uses the terms "two-way" and "round-trip" synonymously.
本备忘录同义使用“双向”和“往返”两个术语。
Many user applications and the transport protocols that make them possible require two-way communications. For example, the TCP SYN->, <-SYN-ACK, ACK-> three-way handshake attempted billions of times each day cannot be completed without two-way connectivity in a near-simultaneous time interval. Thus, measurements of Internet round-trip packet loss performance provide a basis to infer application performance more easily.
许多用户应用程序和使其成为可能的传输协议需要双向通信。例如，每天尝试数十亿次的TCP SYN->、<-SYN-ACK、ACK->三方握手如果没有在几乎同时的时间间隔内进行双向连接，则无法完成。因此，互联网往返丢包性能的测量为更容易地推断应用程序性能提供了基础。
Measurement system designers have also recognized advantages of system simplicity when one host simply echoes or reflects test packets to the sender. Round-trip packet loss measurements are frequently conducted and reported in practice. The ubiquitous "ping" tools allow the measurement of round-trip packet loss and delay but usually require ICMP Echo-Request/Reply support, and ICMP packets may encounter exceptional treatment on the measurement path (see Section 2.6 of [RFC2681]). The Two-Way Active Measurement Protocol (TWAMP) specified in [RFC5357] establishes a round-trip packet loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the [RFC2330] framework.
当一个主机简单地向发送方回送或反映测试数据包时，测量系统设计者也认识到了系统简单性的优点。在实践中，经常进行并报告往返数据包丢失测量。无处不在的“ping”工具允许测量往返数据包丢失和延迟，但通常需要ICMP回送请求/回复支持，ICMP数据包可能会在测量路径上遇到异常处理（见[RFC2681]第2.6节）。[RFC5357]中规定的双向主动测量协议（TWAMP）建立了互联网的往返丢包测量能力。然而，目前没有根据[RFC2330]框架指定往返分组丢失度量。
[RFC2681] indicates that round-trip measurements may sometimes encounter "asymmetric" paths. When loss is observed using a round-trip measurement, there is often a desire to ascertain which of the two directional paths "lost" the packet. Under some circumstances, it is possible to make this inference. The round-trip measurement method raises a few complications when interpreting the embedded one-way results, and the user should be aware of them.
[RFC2681]表示往返测量有时可能会遇到“不对称”路径。当使用往返测量观察到丢失时，通常希望确定两条方向路径中的哪一条“丢失”了数据包。在某些情况下，可以作出这种推断。在解释嵌入的单向结果时，往返测量方法会带来一些复杂问题，用户应该意识到这些问题。
[RFC2681] also points out that loss measurement conducted sequentially in both directions of a path and reported as a round-trip result may be exactly the desired metric. On the other hand, it may be difficult to derive the state of round-trip packet loss from one-way measurements conducted in each direction unless a method to match the appropriate one-way measurements has been pre-arranged.
[RFC2681]还指出，在路径的两个方向上顺序进行并报告为往返结果的损耗测量可能正是所需的度量。另一方面，除非预先安排了匹配适当的单向测量的方法，否则可能难以从在每个方向上进行的单向测量中导出往返分组丢失的状态。
Finally, many measurement systems report statistics on a conditional delay distribution, where the condition is packet arrival at the destination. This condition is encouraged in [RFC3393], [RFC5481],
最后，许多测量系统报告关于条件延迟分布的统计信息，其中条件是数据包到达目的地。[RFC3393]、[RFC5481]中鼓励出现这种情况，
and [RFC6703]. As a result, lost packets need to be reported separately, according to a standardized metric. This memo defines such a metric.
和[RFC6703]。因此，丢失的数据包需要根据标准化指标单独报告。这份备忘录定义了这样一个指标。
See Section 1.1 of [RFC2680] for additional motivation of the packet loss metric.
参见[RFC2680]第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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This memo defines a round-trip packet loss metric using the conventions of the IPPM framework [RFC2330].
本备忘录使用IPPM框架[RFC2330]的约定定义了往返数据包丢失度量。
The memo defines a singleton metric, a sample metric, and a statistic, as per [RFC2330]. The [RFC2330] framework is for active measurement methods. Although this metric MAY be applicable in passive measurement as well, discussion of additional considerations for the passive scenario are beyond the normative scope of this memo.
备忘录根据[RFC2330]定义了单例度量、样本度量和统计。[RFC2330]框架用于主动测量方法。尽管该指标也适用于被动测量，但被动场景的其他考虑事项的讨论超出了本备忘录的规范范围。
The memo also investigates the topic of one-way loss inference from a two-way measurement and lists some key considerations.
备忘录还调查了从双向测量推断单向损失的主题，并列出了一些关键注意事项。
To reduce the redundant information presented in the detailed metrics sections that follow, this section presents the specifications that are common to two or more metrics. The section is organized using the same subsections as the individual metrics, to simplify comparisons.
为了减少后面的详细度量部分中显示的冗余信息，本部分介绍了两个或多个度量的通用规范。本节使用与单个指标相同的小节来组织，以简化比较。
All metrics use the Type-P convention as described in [RFC2330]. The rest of the name is unique to each metric.
所有指标均使用[RFC2330]中所述的P型约定。名称的其余部分对于每个度量都是唯一的。
o Src, the IP address of a host
o Src，主机的IP地址
o Dst, the IP address of a host
o Dst，主机的IP地址
o T, a time (start of test interval)
o T、 a时间（测试间隔的开始）
o Tf, a time (end of test interval)
o Tf，a时间（测试间隔结束）
o lambda, a rate in reciprocal seconds (for Poisson Streams)
o lambda，以倒数秒为单位的速率（对于泊松流）
o incT, the nominal duration of inter-packet interval, first bit to first bit (for Periodic Streams)
o incT，包间间隔的标称持续时间，第一位到第一位（对于周期性流）
o T0, a time that MUST be selected at random from the interval [T, T+dT] to start generating packets and taking measurements (for Periodic Streams)
o T0，必须从间隔[T，T+dT]中随机选择的时间，以开始生成数据包并进行测量（对于周期性流）
o TstampSrc, the wire time of the packet as measured at MP(Src) as it leaves for Dst.
o TstampSrc，数据包离开Dst时在MP（Src）处测得的连线时间。
o TstampDst, the wire time of the packet as measured at MP(Dst), assigned to packets that arrive within a "reasonable" time (less than Tmax).
o TstampDst，在MP（Dst）处测量的数据包的连线时间，分配给在“合理”时间（小于Tmax）内到达的数据包。
o Tmax, a maximum waiting time for packets to arrive at Src, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost).
o Tmax是数据包到达Src的最长等待时间，设置为足够长，以消除丢弃（丢失）数据包中长延迟数据包的歧义。
o M, the total number of packets sent between T0 and Tf
o M、 T0和Tf之间发送的数据包总数
o N, the total number of packets received at Dst (sent between T0 and Tf)
o N、 在Dst接收的数据包总数（在T0和Tf之间发送）
o Type-P, as defined in [RFC2330], which includes any field that may affect a packet's treatment as it traverses the network
o 类型-P，如[RFC2330]中所定义，包括在数据包通过网络时可能影响数据包处理的任何字段
This section is specific to each metric.
本节针对每个指标。
The metric units are logical (1 or 0) when describing a single packet's loss performance, where a 0 indicates successful packet transmission and a 1 indicates packet loss.
当描述单个数据包的丢失性能时，度量单位为逻辑单位（1或0），其中0表示成功的数据包传输，1表示数据包丢失。
Units of time are as specified in [RFC2330].
时间单位如[RFC2330]所规定。
Other units used are defined in the associated section where needed (e.g., Section 6.1 in the case of Type-P-Round-trip-Loss-<Sample>-Ratio).
所使用的其他单位在相关章节中定义（例如，在P型往返损耗率的情况下，第6.1节）。
See Section 3.2.
见第3.2节。
Type-P-Round-trip-Loss SHALL be represented by the binary logical values (or their equivalents) when the following conditions are met:
当满足以下条件时，P型往返损耗应由二进制逻辑值（或其等效值）表示：
Type-P-Round-trip-Loss = 0:
类型-P-往返-损耗=0：
o Src sent the first bit of a Type-P packet to Dst at wire-time TstampSrc,
o Src在连线时间TstampSrc将P型数据包的第一位发送到Dst，
o that Dst received that packet,
o Dst收到了那个数据包，
o the Dst sent a Type-P packet back to the Src as quickly as possible (certainly less than Tmax, and fast enough for the intended purpose), and
o Dst尽快将P型数据包发送回Src（当然小于Tmax，并且足够快，达到预期目的），并且
o that Src received the last bit of the reflected packet prior to wire-time TstampSrc + Tmax.
o 该Src在连线时间TstampSrc+Tmax之前接收到反射包的最后一位。
Type-P-Round-trip-Loss = 1:
类型-P-往返-损耗=1：
o Src sent the first bit of a Type-P packet to Dst at wire-time TstampSrc,
o Src在连线时间TstampSrc将P型数据包的第一位发送到Dst，
o that Src did not receive the last bit of the reflected packet before the waiting time lapsed at TstampSrc + Tmax.
o 在TstampSrc+Tmax处等待时间过去之前，该Src没有接收到反射数据包的最后一位。
Possible causes for the Loss = 1 outcome are as follows:
损失=1结果的可能原因如下：
o the Dst did not receive that packet,
o Dst没有收到该数据包，
o the Dst did not send a Type-P packet back to the Src, or
o Dst没有将P型数据包发送回Src，或者
o the Src did not receive a reflected Type-P packet sent from the Dst.
o Src没有收到从Dst发送的反映的P型数据包。
Following the precedent of Section 2.4 of [RFC2681], we make the simplifying assertion that round-trip loss measured between two hosts is equal regardless of the host that originates the test:
遵循[RFC2681]第2.4节的先例，我们做出简化断言，即无论发起测试的主机是什么，两台主机之间测量的往返损耗都是相等的：
Type-P-Round-trip-Loss(Src->Dst->Src) =
Type-P-Round-trip-Loss(Dst->Src->Dst)
Type-P-Round-trip-Loss(Src->Dst->Src) =
Type-P-Round-trip-Loss(Dst->Src->Dst)
(and agree with the rationale presented there -- that the ambiguity introduced is a small price to pay for measurement efficiency).
（并同意这里提出的理由——引入的模糊性是衡量效率的一个小代价）。
Therefore, each singleton can be represented by pairs of elements as follows:
因此，每个单体可以由成对的元素表示，如下所示：
o TstampSrc, the wire time of the packet at the Src (beginning the round-trip journey).
o TstampSrc，Src处数据包的连线时间（开始往返行程）。
o L, either zero or one (or some logical equivalent), where L=1 indicates loss and L=0 indicates successful round-trip arrival prior to TstampSrc + Tmax.
o 五十、 零或一（或某些逻辑等价物），其中L=1表示丢失，L=0表示在TstampSrc+Tmax之前成功往返到达。
See [RFC2680] and [RFC2681] for extensive discussion, methods of measurement, errors and uncertainties, and other fundamental considerations that need not be repeated here.
请参见[RFC2680]和[RFC2681]，了解此处不需要重复的广泛讨论、测量方法、误差和不确定度以及其他基本注意事项。
We add the following guidance regarding the responder process to "send a Type-P packet back to the Src as quickly as possible".
我们添加了以下关于响应程序流程的指导，以“尽快将P型数据包发送回Src”。
A response that was not generated within Tmax is inadequate for any realistic test, and the Src will discard such responses. A responder that serves typical round-trip packet loss testing (which is relevant to higher-layer application performance) SHOULD produce a response in 1 second or less. A responder that is unable to satisfy this requirement SHOULD log the fact so that an operator can adjust the load and priorities as necessary. Analysis of responder timestamps [RFC5357] that finds responses are not generated in a timely fashion SHOULD result in operator notification, and the operator SHOULD suspend tests to the responder, since it may be overloaded. Additional measurement considerations are described in Section 8 below.
Tmax内未生成的响应不足以进行任何实际测试，Src将丢弃此类响应。服务于典型往返丢包测试（与高层应用程序性能相关）的响应程序应在1秒或更短时间内产生响应。无法满足此要求的响应者应记录事实，以便操作员可以根据需要调整负载和优先级。对响应程序时间戳[RFC5357]的分析发现响应未及时生成，应导致操作员通知，并且操作员应暂停对响应程序的测试，因为它可能过载。下文第8节介绍了其他测量注意事项。
Given the singleton metric Type-P-Round-trip-Loss, we now define one particular sample of such singletons. The idea of the sample is to select a particular binding of the parameters Src, Dst, and Type-P, then define a sample of values of parameter TstampSrc. This can be done in several ways, including the following:
考虑到单例度量类型-P-往返损失，我们现在定义一个此类单例的特定样本。该示例的思想是选择参数Src、Dst和Type-P的特定绑定，然后定义参数TstampSrc值的示例。这可以通过以下几种方式实现：
1. Poisson: a pseudo-random Poisson process of rate lambda, whose values fall between T and Tf. The time interval between successive values of TstampSrc will then average 1/lambda, as per Section 11.1.1 of [RFC2330].
1. 泊松：速率λ的伪随机泊松过程，其值介于T和Tf之间。根据[RFC2330]第11.1.1节，TstampSrc连续值之间的时间间隔将平均为1/lambda。
2. Periodic: a periodic stream process with pseudo-random start time T0 between T and dT, and nominal inter-packet interval incT, as per [RFC3432].
2. 周期性：根据[RFC3432]，周期性流过程的伪随机开始时间T0介于T和dT之间，且标称数据包间隔incT。
In the metric name, the variable <Sample> SHALL be replaced with the process used to define the sample, using one of the above processes (or another sample process meeting the criteria in Section 11.1 of [RFC2330], the details of which MUST be reported with the results if used).
在度量名称中，变量<Sample>应替换为用于定义样本的过程，使用上述过程之一（或满足[RFC2330]第11.1节标准的另一个样本过程，其详细信息必须与结果一起报告（如果使用）。
See Section 3.2.
见第3.2节。
Given one of the methods for defining the test interval -- the sample of times (TstampSrc) and other metric parameters -- we obtain a sequence of Type-P-Round-trip-Loss singletons as defined in Section 4.3.
给出定义测试间隔的方法之一——时间样本（TstampSrc）和其他度量参数——我们获得了第4.3节中定义的P型往返损耗单例序列。
Type-P-Round-trip-Loss-<Sample>-Stream SHALL be a sequence of pairs with elements as follows:
类型-P-往返-损耗-<Sample>-流应为一系列成对元素，如下所示：
o TstampSrc, as above
o TstampSrc，如上所述
o L, either zero or one (or some logical equivalent), where L=1 indicates loss and L=0 indicates successful round-trip arrival prior to TstampSrc + Tmax
o 五十、 零或一（或某些逻辑等价物），其中L=1表示丢失，L=0表示在TstampSrc+Tmax之前成功往返到达
and where <Sample> SHALL be replaced with "Poisson", "Periodic", or an appropriate term to designate another sample method as described in Section 5 above.
其中，<Sample>应替换为“Poisson”、“Periodic”或适当的术语，以指定上文第5节所述的另一种样品方法。
See [RFC2680] and [RFC2681] for extensive discussion, methods of measurement, errors and uncertainties, and other fundamental considerations that need not be repeated here. However, when these references were approved, the packet reordering metrics in [RFC4737] had not yet been defined, nor had reordering been addressed in IPPM methodologies.
请参见[RFC2680]和[RFC2681]，了解此处不需要重复的广泛讨论、测量方法、误差和不确定度以及其他基本注意事项。然而，当这些参考文献获得批准时，[RFC4737]中的数据包重新排序指标尚未定义，IPPM方法中也未涉及重新排序。
[RFC4737] defines packets that arrive "late" with respect to their sending order as reordered -- for example, when packets arrive with sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and they are obviously not lost because they have arrived within some reasonable waiting time threshold. The presence of reordering on a round-trip path has several likely effects on the measurement.
[RFC4737]将相对于其发送顺序“迟到”的数据包定义为重新排序——例如，当数据包以序列号4、7、5、6到达时，则数据包5和6被重新排序，并且它们显然不会丢失，因为它们在某个合理的等待时间阈值内到达。往返路径上存在的重新排序可能会对测量产生一些影响。
1. Methods of measurement should continue to wait the specified time for packets and avoid prematurely declaring round-trip packet loss when a sequence gap or error is observed.
1. 测量方法应继续等待数据包的指定时间，并避免在观察到序列间隔或错误时过早宣布往返数据包丢失。
2. The time distribution of the singletons in the sample has been significantly changed.
2. 样本中单粒子的时间分布发生了显著变化。
3. Either the original packet stream or the reflected packet stream experienced path instability, and the original conditions may no longer be present.
3. 原始分组流或反射分组流经历路径不稳定，并且原始条件可能不再存在。
Measurement implementations MUST address the possibility of packet reordering and avoid related errors in their processes.
度量实现必须解决数据包重新排序的可能性，并在其过程中避免相关错误。
This section gives the primary and overall statistic for loss performance. Additional statistics and metrics originally prepared for one-way loss MAY also be applicable.
本节给出了损失性能的主要统计数据和总体统计数据。最初为单向损失准备的其他统计数据和指标也可能适用。
Given a Type-P-Round-trip-Loss-<Sample>-Stream, the average of all the logical values, L, in the stream is the Type-P-Round-trip-Loss-<Sample>-Ratio. This ratio is in units of lost packets per round-trip transmissions actually attempted.
给定一个P型往返损耗-<Sample>-流，流中所有逻辑值L的平均值就是P型往返损耗-<Sample>-比率。这个比率是以每次实际尝试的往返传输中丢失的数据包为单位的。
In addition, the Type-P-Round-trip-Loss-<Sample>-Ratio is undefined if the sample is empty.
此外，如果样本为空，则类型-P-往返-损耗-<Sample>-比率未定义。
This section raises considerations for results collected using a round-trip measurement architecture, such as in TWAMP [RFC5357].
本节提出了使用往返测量体系结构（如TWAMP[RFC5357]）收集结果的注意事项。
The sampling process for the reverse path (Dst->Src) is a conditional process that depends on successful packet arrival at the Dst and correct operation at the Dst to generate the reflected packet. Therefore, the sampling process for the reverse path will be significantly affected when appreciable loss occurs on the Src->Dst path, making an attempt to assess the reverse path performance invalid (for loss or possibly any metric).
反向路径（Dst->Src）的采样过程是一个有条件的过程，它取决于数据包成功到达Dst以及在Dst正确操作以生成反射数据包。因此，当Src->Dst路径上出现明显损失时，反向路径的采样过程将受到显著影响，从而使评估反向路径性能的尝试无效（对于损失或可能的任何度量）。
Further, the sampling times for the reverse path (Dst->Src) are a random process that depends on the original sample times (TstampSrc), the one-way delay for successful packet arrival at the Dst, and time taken at the Dst to generate the reflected packet. Therefore, the sampling process for the reverse path will be significantly affected when appreciable delay variation occurs on the Src->Dst path, making an attempt to assess the reverse path performance invalid (for loss or possibly any metric).
此外，反向路径（Dst->Src）的采样时间是随机过程，其取决于原始采样时间（TstampSrc）、成功分组到达Dst的单向延迟以及在Dst生成反射分组所花费的时间。因此，当Src->Dst路径上出现明显的延迟变化时，反向路径的采样过程将受到显著影响，从而使评估反向路径性能的尝试无效（损失或可能的任何度量）。
As discussed above in Section 5.4, packet reordering is always a possibility. In addition to the severe delay variation that usually accompanies it, reordering on the Src->Dst path will cause a misalignment of sequence numbers applied at the Dst when compared to the sender numbers. Measurement implementations MUST address this possible outcome.
如上文第5.4节所述，数据包重新排序始终是可能的。除了通常伴随的严重延迟变化外，Src->Dst路径上的重新排序将导致Dst上应用的序列号与发送方编号不一致。度量实现必须解决这个可能的结果。
Prior to conducting this measurement, the participating hosts MUST be configured to send and receive test packets of the chosen Type-P. Standard measurement protocols are capable of this task [RFC5357], but any reliable method is sufficient (e.g., if the issues with ICMP discussed in Section 2.6 of [RFC2681] can be alleviated, and the requirements of Sections 4.3 and 4.4 above are met, then ICMP could be used).
在进行此测量之前，必须将参与主机配置为发送和接收所选P型的测试数据包。标准测量协议能够完成此任务[RFC5357]，但任何可靠的方法都是足够的（例如，如果[RFC2681]第2.6节中讨论的ICMP问题可以缓解，并且满足上述第4.3节和第4.4节的要求，则可以使用ICMP）。
Two key features of the host that receives test packets and returns them to the originating host are described in Section 4.2 of [RFC5357]. Every received test packet MUST result in a responding packet, and the response MUST be generated as quickly as possible. This implies that interface buffers will be serviced promptly and that buffer discards will be extremely rare. These features of the
[RFC5357]第4.2节描述了接收测试数据包并将其返回到原始主机的主机的两个关键特性。每个接收到的测试数据包必须产生一个响应数据包，并且必须尽快生成响应。这意味着接口缓冲区将得到及时的服务，而缓冲区丢弃的情况将极为罕见。这些特点
measurement equipment MUST be calibrated according to Section 3.7.3 of [RFC2679] when operating under a representative measurement load (as defined by the user). Both unexpected test packet discards, and the systematic and random errors and uncertainties, MUST be recorded.
在代表性测量负载（由用户定义）下运行时，必须根据[RFC2679]第3.7.3节校准测量设备。必须记录意外的测试数据包丢弃以及系统和随机错误和不确定性。
We note that Section 4.2.1 of [RFC5357] specifies a method to collect all four significant timestamps needed to describe a packet's round-trip delay [RFC2681] and remove the processing time incurred at the responding host. This information supports the measurement of the corresponding one-way delays encountered on the round-trip path, which can identify path asymmetry or unexpected processing time at the responding host.
我们注意到，[RFC5357]第4.2.1节规定了一种方法，用于收集描述数据包往返延迟[RFC2681]所需的所有四个有效时间戳，并删除响应主机上产生的处理时间。此信息支持测量往返路径上遇到的相应单向延迟，这可以识别路径不对称或响应主机处的意外处理时间。
This metric requires a stream of packets sent from one host (source) to another host (destination) through intervening networks, and back. This method could be abused for denial-of-service attacks directed at the destination and/or the intervening network(s).
此度量要求通过中间网络从一个主机（源）发送到另一个主机（目的地）并返回的数据包流。此方法可能被滥用，用于针对目标和/或介入网络的拒绝服务攻击。
Administrators of source, destination, and intervening network(s) should establish bilateral or multilateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed upon by the participants may be cause for immediate rejection or discard of packets, or other escalation procedures as defined between the affected parties.
源、目的地和干预网络的管理员应就样本指标收集的时间、规模和频率建立双边或多边协议。使用此方法超过参与者同意的条款可能导致立即拒绝或丢弃数据包，或受影响方之间定义的其他升级程序。
Active use of this method generates packets for a sample, rather than taking samples based on user data, and does not threaten user data confidentiality. Passive measurement must restrict attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential. In most cases, a hashing function will produce a value suitable for payload comparisons.
主动使用此方法会为样本生成数据包，而不是基于用户数据采集样本，并且不会威胁用户数据的机密性。被动测量必须将注意力限制在感兴趣的标题上。由于用户有效载荷可能会临时存储以进行长度分析，因此必须采取适当的预防措施以确保该信息的安全和保密。在大多数情况下，哈希函数将生成适合于负载比较的值。
It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g., increasing or decreasing delay) in a way that may distort the measured performance. It may also be
可以识别特定分组或分组流是样本的一部分。利用在目的地和/或介入网络处的该知识，可以以可能扭曲所测量的性能的方式改变分组的处理（例如，增加或减少延迟）。也可能是
possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement.
可能会生成额外的数据包，这些数据包似乎是样本度量的一部分。这些额外的数据包可能会干扰样本测量的结果。
Authentication or encryption techniques, such as digital signatures, MAY be used where appropriate to guard against injected traffic attacks. [RFC5357] includes both authentication and encryption features.
在适当的情况下，可以使用诸如数字签名之类的认证或加密技术来防止注入流量攻击。[RFC5357]包括身份验证和加密功能。
Metrics previously defined in the IETF were registered in the IANA IPPM Metrics Registry; however, this process was discontinued when the registry structure was found to be inadequate, and the registry was declared obsolete [RFC6248].
先前在IETF中定义的指标在IANA IPPM指标注册中心注册；然而，当发现注册表结构不充分，并且注册表被宣布为过时时，该过程被中断[RFC6248]。
Although the metrics in this document may be considered for some form of registration in the future, no IANA action is requested at this time.
尽管本文件中的指标可能会被考虑用于将来的某种形式的注册，但目前不要求IANA采取任何行动。
The author thanks Tiziano Ionta for his careful review of this memo, primarily resulting in the development of measurement considerations using TWAMP [RFC5357] as an example method. The reviews of Adrian Farrel and Benoit Claise also contributed to the clarity of the memo.
作者感谢Tiziano Ionta对本备忘录的仔细审查，主要是以TWAMP[RFC5357]为例，开发了测量注意事项。阿德里安·法雷尔（Adrian Farrel）和贝诺特·克莱斯（Benoit Claise）的评论也有助于备忘录的清晰。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，1998年5月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]Demichelis，C.和P.Chimento，“IP性能度量的IP数据包延迟变化度量（IPPM）”，RFC 3393，2002年11月。
[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月。
[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月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 54812009年3月。
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011.
[RFC6248]Morton，A.，“RFC 4148和IP性能度量（IPPM）度量注册表已过时”，RFC 6248，2011年4月。
[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月。
Author's Address
作者地址
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/