Internet Engineering Task Force (IETF) N. Elkins
Request for Comments: 8250 Inside Products
Category: Standards Track R. Hamilton
ISSN: 2070-1721 Chemical Abstracts Service
M. Ackermann
BCBS Michigan
September 2017
Internet Engineering Task Force (IETF) N. Elkins
Request for Comments: 8250 Inside Products
Category: Standards Track R. Hamilton
ISSN: 2070-1721 Chemical Abstracts Service
M. Ackermann
BCBS Michigan
September 2017
IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
IPv6性能和诊断指标（PDM）目标选项
Abstract
摘要
To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.
为了评估性能问题，本文档描述了嵌入在每个数据包中的可选报头，这些报头提供序列号和计时信息，作为测量的基础。此类测量可实时或事后解释。本文档指定了性能和诊断指标（PDM）目标选项标题。本文件包括PDM测量中的字段限制、计算和使用。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8250.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8250.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Background ......................................................3
1.1. Terminology ................................................3
1.2. Rationale for Defined Solution .............................4
1.3. IPv6 Transition Technologies ...............................4
2. Measurement Information Derived from PDM ........................5
2.1. Round-Trip Delay ...........................................5
2.2. Server Delay ...............................................5
3. Performance and Diagnostic Metrics Destination Option Layout ....6
3.1. Destination Options Header .................................6
3.2. Performance and Diagnostic Metrics Destination Option ......6
3.2.1. PDM Layout ..........................................6
3.2.2. Base Unit for Time Measurement ......................8
3.3. Header Placement ...........................................9
3.4. Header Placement Using IPsec ESP Mode ......................9
3.4.1. Using ESP Transport Mode ...........................10
3.4.2. Using ESP Tunnel Mode ..............................10
3.5. Implementation Considerations .............................10
3.5.1. PDM Activation .....................................10
3.5.2. PDM Timestamps .....................................10
3.6. Dynamic Configuration Options .............................11
3.7. Information Access and Storage ............................11
4. Security Considerations ........................................11
4.1. Resource Consumption and Resource Consumption Attacks .....11
4.2. Pervasive Monitoring ......................................12
4.3. PDM as a Covert Channel ...................................12
4.4. Timing Attacks ............................................13
5. IANA Considerations ............................................13
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................14
1. Background ......................................................3
1.1. Terminology ................................................3
1.2. Rationale for Defined Solution .............................4
1.3. IPv6 Transition Technologies ...............................4
2. Measurement Information Derived from PDM ........................5
2.1. Round-Trip Delay ...........................................5
2.2. Server Delay ...............................................5
3. Performance and Diagnostic Metrics Destination Option Layout ....6
3.1. Destination Options Header .................................6
3.2. Performance and Diagnostic Metrics Destination Option ......6
3.2.1. PDM Layout ..........................................6
3.2.2. Base Unit for Time Measurement ......................8
3.3. Header Placement ...........................................9
3.4. Header Placement Using IPsec ESP Mode ......................9
3.4.1. Using ESP Transport Mode ...........................10
3.4.2. Using ESP Tunnel Mode ..............................10
3.5. Implementation Considerations .............................10
3.5.1. PDM Activation .....................................10
3.5.2. PDM Timestamps .....................................10
3.6. Dynamic Configuration Options .............................11
3.7. Information Access and Storage ............................11
4. Security Considerations ........................................11
4.1. Resource Consumption and Resource Consumption Attacks .....11
4.2. Pervasive Monitoring ......................................12
4.3. PDM as a Covert Channel ...................................12
4.4. Timing Attacks ............................................13
5. IANA Considerations ............................................13
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................14
Appendix A. Context for PDM .......................................15
A.1. End-User Quality of Service (QoS) ..........................15
A.2. Need for a Packet Sequence Number (PSN) ....................15
A.3. Rationale for Defined Solution .............................15
A.4. Use PDM with Other Headers .................................16
Appendix B. Timing Considerations .................................16
B.1. Calculations of Time Differentials .........................16
B.2. Considerations of This Time-Differential Representation ....18
B.2.1. Limitations with This Encoding Method ..................18
B.2.2. Loss of Precision Induced by Timer Value Truncation ....19
Appendix C. Sample Packet Flows ...................................20
C.1. PDM Flow - Simple Client-Server Traffic ....................20
C.1.1. Step 1 .................................................20
C.1.2. Step 2 .................................................21
C.1.3. Step 3 .................................................21
C.1.4. Step 4 .................................................23
C.1.5. Step 5 .................................................24
C.2. Other Flows ................................................24
C.2.1. PDM Flow - One-Way Traffic .............................24
C.2.2. PDM Flow - Multiple-Send Traffic .......................25
C.2.3. PDM Flow - Multiple-Send Traffic with Errors ...........26
Appendix D. Potential Overhead Considerations .....................28
Acknowledgments ...................................................30
Authors' Addresses ................................................30
Appendix A. Context for PDM .......................................15
A.1. End-User Quality of Service (QoS) ..........................15
A.2. Need for a Packet Sequence Number (PSN) ....................15
A.3. Rationale for Defined Solution .............................15
A.4. Use PDM with Other Headers .................................16
Appendix B. Timing Considerations .................................16
B.1. Calculations of Time Differentials .........................16
B.2. Considerations of This Time-Differential Representation ....18
B.2.1. Limitations with This Encoding Method ..................18
B.2.2. Loss of Precision Induced by Timer Value Truncation ....19
Appendix C. Sample Packet Flows ...................................20
C.1. PDM Flow - Simple Client-Server Traffic ....................20
C.1.1. Step 1 .................................................20
C.1.2. Step 2 .................................................21
C.1.3. Step 3 .................................................21
C.1.4. Step 4 .................................................23
C.1.5. Step 5 .................................................24
C.2. Other Flows ................................................24
C.2.1. PDM Flow - One-Way Traffic .............................24
C.2.2. PDM Flow - Multiple-Send Traffic .......................25
C.2.3. PDM Flow - Multiple-Send Traffic with Errors ...........26
Appendix D. Potential Overhead Considerations .....................28
Acknowledgments ...................................................30
Authors' Addresses ................................................30
To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real time or after the fact.
为了评估性能问题，可以在每个数据包中嵌入基于可选序列号和定时的测量。此类测量可实时或事后解释。
As defined in RFC 8200 [RFC8200], destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 node given as the destination address in the IPv6 header, not by routers or other "middleboxes". This document specifies the Performance and Diagnostic Metrics (PDM) destination option. The field limits, calculations, and usage in measurement of the PDM Destination Options header are included in this document.
如RFC 8200[RFC8200]中所定义，目标选项由IPv6目标选项扩展标头携带。目标选项包括可选信息，这些信息只需要由IPv6头中作为目标地址给定的IPv6节点检查，而不需要由路由器或其他“中间盒”检查。本文档规定了性能和诊断指标（PDM）目标选项。本文档包括PDM目标选项标题的字段限制、计算和测量使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The current IPv6 specification does not provide timing, nor does it provide a similar field in the IPv6 main header or in any extension header. The IPv6 PDM destination option provides such fields.
当前的IPv6规范没有提供时间，也没有在IPv6主标头或任何扩展标头中提供类似字段。IPv6 PDM目标选项提供了此类字段。
Advantages include:
优点包括：
1. Real measure of actual transactions.
1. 实际交易的真实度量。
2. Ability to span organizational boundaries with consistent instrumentation.
2. 能够通过一致的工具跨越组织边界。
3. No time synchronization needed between session partners.
3. 会话伙伴之间不需要时间同步。
4. Ability to handle all transport protocols (TCP, UDP, the Stream Control Transmission Protocol (SCTP), etc.) in a uniform way.
4. 能够以统一的方式处理所有传输协议（TCP、UDP、流控制传输协议（SCTP）等）。
PDM provides the ability to determine quickly if the (latency) problem is in the network or in the server (application). That is, it is a fast way to do triage. For more information on the background and usage of PDM, see Appendix A.
PDM能够快速确定（延迟）问题是在网络中还是在服务器（应用程序）中。也就是说，这是一种快速的分类方法。有关PDM背景和用途的更多信息，请参见附录A。
In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed. It is possible that an IPv6 packet containing PDM may be dropped if using IPv6 transition technologies. For example, an implementation using a translation technique (IPv6 to IPv4) that does not support or recognize the IPv6 Destination Options extension header may simply drop the packet rather than translating it without the extension header.
在全面实施IPv6的过程中，可以采用转换或隧道等过渡技术。如果使用IPv6转换技术，可能会丢弃包含PDM的IPv6数据包。例如，使用不支持或不识别IPv6目标选项扩展报头的转换技术（IPv6到IPv4）的实现可能只是丢弃数据包，而不是在没有扩展报头的情况下对其进行转换。
It is also possible that some devices in the network may not correctly handle multiple IPv6 extension headers, including the IPv6 Destination Option. For example, adding the PDM header to a packet may push the Layer 4 information to a point in the packet where it is not visible to filtering logic, and the packet may be dropped. This kind of situation is expected to become rare over time.
网络中的某些设备也可能无法正确处理多个IPv6扩展头，包括IPv6目标选项。例如，向分组添加PDM报头可以将第4层信息推送到分组中过滤逻辑看不到的点，并且分组可以被丢弃。随着时间的推移，这种情况预计将变得罕见。
Each packet contains information about the sender and receiver. In IP, the identifying information is called a "5-tuple".
每个数据包都包含有关发送方和接收方的信息。在IP中，标识信息称为“5元组”。
The 5-tuple consists of:
5元组包括：
SADDR: IP address of the sender SPORT: Port for the sender DADDR: IP address of the destination DPORT: Port for the destination PROTC: Upper-layer protocol (TCP, UDP, ICMP, etc.)
SADDR：发送方的IP地址SPORT：发送方的端口DADDR：目的地的IP地址DPORT：目的地的端口PROTC：上层协议（TCP、UDP、ICMP等）
PDM contains the following base fields (scale fields intentionally left out):
PDM包含以下基本字段（故意省略的比例字段）：
PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTATLR: Delta Time Last Received DELTATLS: Delta Time Last Sent
PSNTP：数据包序列号此数据包PSNLR：数据包序列号上次接收增量LR：增量时间上次接收增量LS：增量时间上次发送
Other fields for storing time scaling factors are also in PDM and will be described in Section 3.
用于存储时间比例因子的其他字段也在PDM中，将在第3节中描述。
This information, combined with the 5-tuple, allows the measurement of the following metrics:
此信息与5元组相结合，允许测量以下指标：
1. Round-trip delay
1. 往返延误
2. Server delay
2. 服务器延迟
Round-trip *network* delay is the delay for packet transfer from a source host to a destination host and then back to the source host. This measurement has been defined, and its advantages and disadvantages are discussed in "A Round-trip Delay Metric for IPPM" [RFC2681].
往返*网络*延迟是数据包从源主机传输到目标主机然后再返回源主机的延迟。已对该测量进行了定义，其优缺点在“IPPM的往返延迟度量”[RFC2681]中进行了讨论。
Server delay is the interval between when a packet is received by a device and the first corresponding packet is sent back in response. This may be "server processing time". It may also be a delay caused by acknowledgments. Server processing time includes the time taken by the combination of the stack and application to return the response. The stack delay may be related to network performance. If this aggregate time is seen as a problem and there is a need to make
服务器延迟是设备接收到数据包和第一个相应数据包作为响应发送回之间的间隔。这可能是“服务器处理时间”。它也可能是由确认引起的延迟。服务器处理时间包括堆栈和应用程序组合返回响应所花费的时间。堆栈延迟可能与网络性能有关。如果总时间被视为一个问题，需要
a clear distinction between application processing time and stack delay, including that caused by the network, then more client-based measurements are needed.
明确区分应用程序处理时间和堆栈延迟（包括由网络引起的延迟），然后需要更多基于客户端的测量。
The IPv6 Destination Options extension header [RFC8200] is used to carry optional information that needs to be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header and is defined in RFC 8200 [RFC8200]. The IPv6 Performance and Diagnostic Metrics (PDM) destination option is implemented as an IPv6 Option carried in the Destination Options header. PDM does not require time synchronization.
IPv6目的地选项扩展标头[RFC8200]用于承载仅需由数据包的目的地节点检查的可选信息。目标选项标头由前一个标头中的下一个标头值60标识，并在RFC 8200[RFC8200]中定义。IPv6 Performance and Diagnostic Metrics（PDM）目标选项实现为目标选项标头中携带的IPv6选项。PDM不需要时间同步。
The IPv6 PDM destination option contains the following fields:
IPv6 PDM目标选项包含以下字段：
SCALEDTLR: Scale for Delta Time Last Received SCALEDTLS: Scale for Delta Time Last Sent PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTATLR : Delta Time Last Received DELTATLS : Delta Time Last Sent
SCALEDTLR：上次接收增量时间的比例SCALEDTLS：上次发送增量时间的比例PSNTP：数据包序列号此数据包PSNLR：数据包序列号上次接收增量LR：上次接收增量时间增量TLS：上次发送增量时间
PDM has alignment requirements. Following the convention in IPv6, these options are aligned in a packet so that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8) [RFC8200].
PDM具有校准要求。按照IPv6中的约定，这些选项在数据包中对齐，以便每个选项的选项数据字段中的多个八位字节值落在自然边界上（即，宽度为n个八位字节的字段从报头开始以n个八位字节的整数倍放置，表示n=1、2、4或8）[RFC8200]。
The PDM destination option is encoded in type-length-value (TLV) format as follows:
PDM目标选项以类型长度值（TLV）格式编码，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | ScaleDTLR | ScaleDTLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN This Packet | PSN Last Received |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time Last Received | Delta Time Last Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | ScaleDTLR | ScaleDTLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN This Packet | PSN Last Received |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time Last Received | Delta Time Last Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
选项类型
0x0F
0x0F
In keeping with RFC 8200 [RFC8200], the two high-order bits of the Option Type field are encoded to indicate specific processing of the option; for the PDM destination option, these two bits MUST be set to 00.
根据RFC 8200[RFC8200]，对选项类型字段的两个高阶位进行编码，以指示选项的特定处理；对于PDM目标选项，这两位必须设置为00。
The third high-order bit of the Option Type field specifies whether or not the Option Data of that option can change en route to the packet's final destination.
选项类型字段的第三个高位指定该选项的选项数据是否可以在到数据包最终目的地的途中更改。
In PDM, the value of the third high-order bit MUST be 0.
在PDM中，第三个高位的值必须为0。
Option Length
选项长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 10.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和选项长度字段。此字段必须设置为10。
Scale Delta Time Last Received (SCALEDTLR)
上次接收的刻度增量时间（刻度增量LR）
8-bit unsigned integer. This is the scaling value for the Delta Time Last Received (DELTATLR) field. The possible values are from 0 to 255. See Appendix B for further discussion on timing considerations and formatting of the scaling values.
8位无符号整数。这是上次接收的增量时间（DELTATLR）字段的缩放值。可能的值为0到255。有关定时注意事项和缩放值格式的进一步讨论，请参见附录B。
Scale Delta Time Last Sent (SCALEDTLS)
上次发送的缩放增量时间（缩放增量）
8-bit signed integer. This is the scaling value for the Delta Time Last Sent (DELTATLS) field. The possible values are from 0 to 255.
8位有符号整数。这是上次发送的增量时间（DELTATLS）字段的缩放值。可能的值为0到255。
Packet Sequence Number This Packet (PSNTP)
此数据包的数据包序列号（PSNTP）
16-bit unsigned integer. This field will wrap. It is intended for use while analyzing packet traces.
16位无符号整数。此字段将换行。它用于分析数据包跟踪。
This field is initialized at a random number and incremented monotonically for each packet of the session flow of the 5-tuple. The random-number initialization is intended to make it harder to spoof and insert such packets.
该字段以随机数初始化，并针对5元组会话流的每个数据包单调递增。随机数初始化旨在使欺骗和插入此类数据包变得更加困难。
Operating systems MUST implement a separate packet sequence number counter per 5-tuple.
操作系统必须为每个5元组实现一个单独的数据包序列号计数器。
Packet Sequence Number Last Received (PSNLR)
上次接收的数据包序列号（PSNLR）
16-bit unsigned integer. This is the PSNTP of the packet last received on the 5-tuple.
16位无符号整数。这是上次在5元组上接收到的数据包的PSNTP。
This field is initialized to 0.
此字段已初始化为0。
Delta Time Last Received (DELTATLR)
上次接收的增量时间（增量LR）
16-bit unsigned integer. The value is set according to the scale in SCALEDTLR.
16位无符号整数。该值根据SCALEDTLR中的比例设置。
Delta Time Last Received = (send time packet n - receive time packet (n - 1))
上次接收的增量时间=（发送时间包n-接收时间包（n-1））
Delta Time Last Sent (DELTATLS)
上次发送的增量时间（增量）
16-bit unsigned integer. The value is set according to the scale in SCALEDTLS.
16位无符号整数。该值是根据SCALEDTLS中的比例设置的。
Delta Time Last Sent = (receive time packet n - send time packet (n - 1))
上次发送的增量时间=（接收时间包n-发送时间包（n-1））
A time differential is always a whole number in a CPU; it is the unit specification -- hours, seconds, nanoseconds -- that determines what the numeric value means. For PDM, the base time unit is 1 attosecond (asec). This allows for a common unit and scaling of the time differential among all IP stacks and hardware implementations.
时间差在CPU中总是一个整数；单位规格——小时、秒、纳秒——决定了数值的含义。对于PDM，基本时间单位为1阿秒（asec）。这允许在所有IP堆栈和硬件实现中使用一个公共单元并缩放时间差。
Note that PDM provides the ability to measure both time differentials that are extremely small and time differentials in a Delay/Disruption Tolerant Networking (DTN) environment where the delays may be very great. To store a time differential in just 16 bits that must range in this way will require some scaling of the time-differential value.
请注意，PDM能够测量非常小的时间差和延迟/中断容忍网络（DTN）环境中的时间差，其中延迟可能非常大。要将时间差仅存储在16位中（必须以这种方式设置范围），需要对时间差数值进行一些缩放。
One issue is the conversion from the native time base in the CPU hardware of whatever device is in use to some number of attoseconds. It might seem that this will be an astronomical number, but the conversion is straightforward. It involves multiplication by an appropriate power of 10 to change the value into a number of attoseconds. Then, to scale the value so that it fits into DELTATLR or DELTATLS, the value is shifted by a number of bits, retaining the 16 high-order or most significant bits. The number of bits shifted becomes the scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For additional information on this process, see Appendix B.
一个问题是从CPU硬件中使用的任何设备的本机时基转换为若干秒。这似乎是一个天文数字，但转换很简单。它需要乘以适当的10次方，将数值转换为阿秒数。然后，为了缩放该值，使其适合于DELTATLR或DELTATLS，将该值移位若干位，保留16个高阶或最高有效位。移位的位数成为缩放因子，分别存储为SCALEDTLR或SCALEDTLS。有关此过程的更多信息，请参见附录B。
The PDM destination option is placed as defined in RFC 8200 [RFC8200]. There may be a choice of where to place the Destination Options header. If using Encapsulating Security Payload (ESP) mode, please see Section 3.4 of this document regarding the placement of the PDM Destination Options header.
PDM目的地选项按照RFC 8200[RFC8200]中的定义放置。可以选择放置目标选项标题的位置。如果使用封装安全有效负载（ESP）模式，请参阅本文档第3.4节，了解PDM目标选项标题的位置。
For each IPv6 packet header, PDM MUST NOT appear more than once. However, an encapsulated packet MAY contain a separate PDM associated with each encapsulated IPv6 header.
对于每个IPv6数据包头，PDM不得出现多次。然而，封装的分组可以包含与每个封装的IPv6报头相关联的单独的PDM。
IPsec ESP is defined in [RFC4303] and is widely used. Section 3.1.1 of [RFC4303] discusses the placement of Destination Options headers.
IPsec ESP在[RFC4303]中定义并得到广泛使用。[RFC4303]第3.1.1节讨论了目标选项标题的放置。
The placement of PDM is different, depending on whether ESP is used in tunnel mode or transport mode.
PDM的位置不同，这取决于ESP是在隧道模式下使用还是在运输模式下使用。
In the ESP case, no 5-tuple is available, as there are no port numbers. ESP flow should be identified only by using SADDR, DADDR, and PROTC. The Security Parameter Index (SPI) numbers SHOULD be ignored when considering the flow over which PDM information is measured.
在ESP的情况下，没有5元组可用，因为没有端口号。ESP流量只能通过SADD、DADDR和PROTC进行识别。在考虑PDM信息的测量流程时，应忽略安全参数索引（SPI）编号。
Note that destination options may be placed before or after ESP, or both. If using PDM in ESP transport mode, PDM MUST be placed after the ESP header so as not to leak information.
请注意，目的地选项可以放在ESP之前或之后，或者两者都可以。如果在ESP运输模式下使用PDM，则必须将PDM放在ESP收割台之后，以免泄漏信息。
Note that in both the outer set of IP headers and the inner set of IP headers, destination options may be placed before or after ESP, or both. A tunnel endpoint that creates a new packet may decide to use PDM independently of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints.
请注意，在外部IP头集和内部IP头集中，目标选项可以放在ESP之前或之后，或者两者都可以。创建新分组的隧道端点可以决定独立于原始分组的PDM的使用而使用PDM，以实现两个隧道端点之间的延迟测量。
An implementation should provide an interface to enable or disable the use of PDM. This specification recommends having PDM off by default.
实施应提供启用或禁用PDM的接口。本规范建议在默认情况下关闭PDM。
PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device.
仅当接收到带有PDM报头的数据包时，不得打开PDM。接收到的数据包可能被其他设备欺骗。
The PDM timestamps are intended to isolate wire time from server or host time but may necessarily attribute some host processing time to network latency.
PDM时间戳旨在将连线时间与服务器或主机时间隔离开来，但可能必然会将某些主机处理时间归因于网络延迟。
Section 10.2 of RFC 2330 [RFC2330] ("Framework for IP Performance Metrics") describes two notions of "wire time". These notions are only defined in terms of an Internet host H observing an Internet link L at a particular location:
RFC 2330[RFC2330]（“IP性能度量框架”）第10.2节描述了“连线时间”的两个概念。这些概念仅根据在特定位置观察因特网链路L的因特网主机H来定义：
+ For a given IP packet P, the "wire arrival time" of P at H on L is the first time T at which any bit of P has appeared at H's observational position on L.
+ 对于给定的IP分组P，P在L上的H处的“有线到达时间”是P的任何比特在L上的H的观测位置出现的第一时间T。
+ For a given IP packet P, the "wire exit time" of P at H on L is the first time T at which all the bits of P have appeared at H's observational position on L.
+ 对于给定的IP分组P，P在L上的H处的“连线退出时间”是P的所有比特第一次出现在L上的H的观测位置的时间T。
This specification does not define H's exact observational position on L. That is left for the deployment setups to define. However, the position where PDM timestamps are taken SHOULD be as close to the physical network interface as possible. Not all implementations will be able to achieve the ideal level of measurement.
本规范未定义H在L上的确切观测位置。该位置留给部署设置来定义。但是，采用PDM时间戳的位置应尽可能靠近物理网络接口。并不是所有的实现都能达到理想的测量水平。
If the PDM Destination Options header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc.), a local port, or IP address only. These are at the discretion of the implementation.
如果使用PDM Destination Options报头，则可以为流经主机的所有数据包启用该报头，该报头仅应用于上层协议（TCP、UDP、SCTP等）、本地端口或IP地址。这些由实施部门自行决定。
Measurement information provided by PDM may be made accessible for higher layers or the user itself. Similar to activating the use of PDM, the implementation may also provide an interface to indicate if received.
PDM提供的测量信息可供更高层或用户自己访问。与激活PDM的使用类似，该实现还可以提供一个接口来指示是否接收到。
PDM information may be stored, if desired. If a packet with PDM information is received and the information should be stored, the upper layers may be notified. Furthermore, the implementation should define a configurable maximum lifetime after which the information can be removed as well as a configurable maximum amount of memory that should be allocated for PDM information.
如果需要，可以存储PDM信息。如果接收到包含PDM信息的数据包，并且应存储该信息，则可能会通知上层。此外，实施应定义一个可配置的最大生存期，在此之后可以删除信息，以及应为PDM信息分配的可配置最大内存量。
PDM may introduce some new security weaknesses.
PDM可能会引入一些新的安全弱点。
PDM needs to calculate the deltas for time and keep track of the sequence numbers. This means that control blocks that reside in memory may be kept at the end hosts per 5-tuple.
PDM需要计算时间的增量并跟踪序列号。这意味着驻留在内存中的控制块可以每5元组保留在终端主机上。
A limit on how much memory is being used SHOULD be implemented.
应该对正在使用的内存进行限制。
Without a memory limit, any time that a control block is kept in memory, an attacker can try to misuse the control blocks to cause excessive resource consumption. This could be used to compromise the end host.
在没有内存限制的情况下，控制块保留在内存中的任何时候，攻击者都可以尝试滥用控制块以导致过度的资源消耗。这可能会危及终端主机。
PDM is used only at the end hosts, and memory is used only at the end host and not at routers or middleboxes.
PDM仅在终端主机上使用，内存仅在终端主机上使用，而不在路由器或中间盒上使用。
Since PDM passes in the clear, a concern arises as to whether the data can be used to fingerprint the system or somehow obtain information about the contents of the payload.
由于PDM以明文形式通过，因此会出现一个问题，即数据是否可用于对系统进行指纹识别或以某种方式获取有关有效负载内容的信息。
Let us discuss fingerprinting of the end host first. It is possible that seeing the pattern of deltas or the absolute values could give some information as to the speed of the end host -- that is, if it is a very fast system or an older, slow device. This may be useful to the attacker. However, if the attacker has access to PDM, the attacker also has access to the entire packet and could make such a deduction based merely on the time frames elapsed between packets WITHOUT PDM.
让我们先讨论终端主机的指纹识别。看到Delta的模式或绝对值可能会给出一些关于终端主机速度的信息——也就是说，如果它是一个非常快的系统或一个旧的、缓慢的设备。这可能对攻击者有用。但是，如果攻击者可以访问PDM，则攻击者也可以访问整个数据包，并且可以仅根据没有PDM的数据包之间经过的时间帧进行推断。
As far as deducing the content of the payload, in terms of the application-level information such as web page, user name, user password, and so on, it appears to us that PDM is quite unhelpful in this regard. Having said that, the ability to separate wire time from processing time may potentially provide an attacker with additional information. It is conceivable that an attacker could attempt to deduce the type of application in use by noting the server time and payload length. Some encryption algorithms attempt to obfuscate the packet length to avoid just such vulnerabilities. In the future, encryption algorithms may wish to obfuscate the server time as well.
就推断有效负载的内容而言，就应用程序级信息（如网页、用户名、用户密码等）而言，PDM在这方面似乎没有什么帮助。话虽如此，将连线时间与处理时间分开的能力可能会为攻击者提供额外的信息。可以想象，攻击者可以通过记录服务器时间和有效负载长度来推断正在使用的应用程序类型。一些加密算法试图混淆数据包长度以避免此类漏洞。将来，加密算法可能也希望混淆服务器时间。
PDM provides a set of fields in the packet that could be used to leak data. But there is no real reason to suspect that PDM would be chosen rather than another part of the payload or another extension header.
PDM在数据包中提供了一组可用于泄漏数据的字段。但没有真正的理由怀疑选择PDM而不是负载的另一部分或另一个扩展头。
A firewall or another device could sanity-check the fields within PDM, but randomly assigned sequence numbers and delta times might be expected to vary widely. The biggest problem, though, is how an attacker would get access to PDM in the first place to leak data. The attacker would have to either compromise the end host or have a Man in the Middle (MitM). It is possible that either one could change the fields, but the other end host would then get sequence numbers and deltas that don't make any sense.
防火墙或其他设备可以对PDM中的字段进行健全检查，但随机分配的序列号和增量时间可能会有很大差异。不过，最大的问题是，攻击者如何首先访问PDM以泄漏数据。攻击者将不得不妥协的最终主机或有一个人在中间（MITM）。有可能其中一个可以更改字段，但另一个终端主机将获得毫无意义的序列号和增量。
It is conceivable that someone could compromise an end host and make it start sending packets with PDM without the knowledge of the host. But, again, the bigger problem is the compromise of the end host. Once that is done, the attacker probably has better ways to leak data.
可以想象，有人可能会破坏终端主机，使其在不知道主机的情况下开始使用PDM发送数据包。但是，更大的问题是终端主机的妥协。一旦完成，攻击者可能有更好的方法泄漏数据。
Having said that, if a PDM-aware middlebox or an implementation (destination host) detects some number of "nonsensical" sequence numbers or timing information, it could take action to block this traffic, discard it, or send an alert.
话虽如此，如果支持PDM的中间盒或实现（目标主机）检测到一些“无意义”的序列号或定时信息，它可以采取措施阻止该流量、丢弃该流量或发送警报。
The fact that PDM can help in the separation of node processing time from network latency brings value to performance monitoring. Yet, it is this very characteristic of PDM that may be misused to make certain new types of timing attacks against protocols and implementations possible.
PDM有助于将节点处理时间与网络延迟分离，这一事实为性能监控带来了价值。然而，正是PDM的这一特性可能被滥用，使针对协议和实现的某些新型定时攻击成为可能。
Depending on the nature of the cryptographic protocol used, it may be possible to leak the credentials of the device. For example, if an attacker can see that PDM is being used, then the attacker might use PDM to launch a timing attack against the keying material used by the cryptographic protocol.
根据所用加密协议的性质，可能会泄漏设备的凭据。例如，如果攻击者可以看到正在使用PDM，则攻击者可能会使用PDM对加密协议使用的密钥材料发起定时攻击。
An implementation may want to be sure that PDM is enabled only for certain IP addresses or only for some ports. Additionally, the implementation SHOULD require an explicit restart of monitoring after a certain time period (for example, after 1 hour) to make sure that PDM is not accidentally left on (for example, after debugging has been done).
实现可能需要确保仅对某些IP地址或某些端口启用PDM。此外，实施应要求在特定时间段后（例如，1小时后）明确重新启动监控，以确保PDM不会意外打开（例如，调试完成后）。
Even so, if using PDM, a user "Consent to be Measured" SHOULD be a prerequisite for using PDM. Consent is common in enterprises and with some subscription services. The actual content of "Consent to be Measured" will differ by site, but it SHOULD make clear that the traffic is being measured for Quality of Service (QoS) and to assist in diagnostics, as well as to make clear that there may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session.
即便如此，如果使用PDM，用户“同意测量”应是使用PDM的先决条件。同意在企业和某些订阅服务中很常见。“测量同意书”的实际内容因站点而异，但应明确测量流量是为了服务质量（QoS）和帮助诊断，并明确如果在诊断会话期间捕获流量，可能存在某些漏洞的潜在风险。
IANA has registered a Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0 from the "Destination Options and Hop-by-Hop Options" sub-registry of the "Internet Protocol Version 6 (IPv6) Parameters" registry [RFC2780] at <https://www.iana.org/assignments/ipv6-parameters/>.
IANA已在“Internet协议版本6（IPv6）参数”注册表[RFC2780]的“目标选项和逐跳选项”子注册表中注册了目标选项类型分配，act位设置为00，chg位设置为0<https://www.iana.org/assignments/ipv6-parameters/>.
Hex Value Binary Value Description Reference
act chg rest
---------------------------------------------------------------------
0x0F 00 0 01111 Performance and RFC 8250
Diagnostic Metrics (PDM)
Hex Value Binary Value Description Reference
act chg rest
---------------------------------------------------------------------
0x0F 00 0 01111 Performance and RFC 8250
Diagnostic Metrics (PDM)
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC2681]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，DOI 10.17487/RFC26811999年9月<https://www.rfc-editor.org/info/rfc2681>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <https://www.rfc-editor.org/info/rfc2780>.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，DOI 10.17487/RFC2780，2000年3月<https://www.rfc-editor.org/info/rfc2780>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<https://www.rfc-editor.org/info/rfc4303>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，DOI 10.17487/RFC2330，1998年5月<https://www.rfc-editor.org/info/rfc2330>.
[TCPM] Scheffenegger, R., Kuehlewind, M., and B. Trammell, "Encoding of Time Intervals for the TCP Timestamp Option", Work in Progress, draft-trammell-tcpm-timestamp-interval-01, July 2013.
[TCPM]Scheffenegger，R.，Kuehlewind，M.，和B.Trammell，“TCP时间戳选项的时间间隔编码”，在建工程，草稿-Trammell-TCPM-Timestamp-interval-012013年7月。
The timing values in PDM embedded in the packet will be used to estimate QoS as experienced by an end-user device.
数据包中嵌入的PDM中的定时值将用于估计最终用户设备所经历的QoS。
For many applications, the key user performance indicator is response time. When the end user is an individual, he is generally indifferent to what is happening along the network; what he really cares about is how long it takes to get a response back. But this is not just a matter of individuals' personal convenience. In many cases, rapid response is critical to the business being conducted.
对于许多应用程序，关键的用户性能指标是响应时间。当终端用户是个人时，他通常对网络上发生的事情漠不关心；他真正关心的是回复需要多长时间。但这不仅仅是个人便利的问题。在许多情况下，快速响应对正在开展的业务至关重要。
Low, reliable, and acceptable response times are not just "nice to have". On many networks, the impact can be financial hardship or can endanger human life. In some cities, the emergency police contact system operates over IP; all levels of law enforcement use IP networks; transactions on our stock exchanges are settled using IP networks. The critical nature of such activities to our daily lives and financial well-being demands a simple solution to support response-time measurements.
低、可靠和可接受的响应时间不仅仅是“好的”。在许多网络上，影响可能是经济困难，也可能危及人的生命。在一些城市，应急警察联系系统通过IP运行；各级执法部门使用IP网络；我们证券交易所的交易通过IP网络结算。这些活动对我们的日常生活和财务状况至关重要，因此需要一个简单的解决方案来支持响应时间测量。
While performing network diagnostics on an end-to-end connection, it often becomes necessary to isolate the factors along the network path responsible for problems. Diagnostic data may be collected at multiple places along the path (if possible), or at the source and destination. Then, in post-collection processing, the diagnostic data corresponding to each packet at different observation points must be matched for proper measurements. A sequence number in each packet provides a sufficient basis for the matching process. If need be, the timing fields may be used along with the sequence number to ensure uniqueness.
在端到端连接上执行网络诊断时，通常需要隔离网络路径上导致问题的因素。诊断数据可以在路径沿线的多个位置（如果可能）或在源和目标处收集。然后，在采集后处理中，必须匹配不同观测点处每个数据包对应的诊断数据，以便进行适当的测量。每个数据包中的序列号为匹配过程提供了充分的基础。如果需要，可以将计时字段与序列号一起使用，以确保唯一性。
This method of data collection along the path is of special use for determining where packet loss or packet corruption is happening.
这种沿路径收集数据的方法特别适用于确定发生数据包丢失或数据包损坏的位置。
The packet sequence number needs to be unique in the context of the session (5-tuple).
在会话上下文中，数据包序列号必须是唯一的（5元组）。
One of the important functions of PDM is to allow you to quickly dispatch the right set of diagnosticians. Within network or server latency, there may be many components. The job of the diagnostician is to rule each one out until the culprit is found.
PDM的一个重要功能是允许您快速派遣正确的诊断专家。在网络或服务器延迟内，可能有许多组件。诊断师的工作是将每个人排除在外，直到找到罪犯。
PDM will fit into this diagnostic picture by quickly telling you how to escalate. PDM will point to either the network area or the server area. Within the server latency, PDM does not tell you whether the bottleneck is in the IP stack, the application, or buffer allocation. Within the network latency, PDM does not tell you which of the network segments or middleboxes is at fault.
PDM将通过快速告诉您如何升级来适应此诊断画面。PDM将指向网络区域或服务器区域。在服务器延迟内，PDM不会告诉您瓶颈是在IP堆栈、应用程序还是缓冲区分配中。在网络延迟内，PDM不会告诉您哪个网段或中间盒出现故障。
What PDM does tell you is whether the problem is in the network or the server.
PDM告诉您的是问题出在网络还是服务器上。
For diagnostics, one may want to use PDM with other headers (Layer 2, Layer 3, etc). For example, if PDM is used by a technician (or tool) looking at a packet capture, within the packet capture, they would have available to them the Layer 2 header, IP header (v6 or v4), TCP header, UDP header, ICMP header, SCTP header, or other headers. All information would be looked at together to make sense of the packet flow. The technician or processing tool could analyze, report, or ignore the data from PDM, as necessary.
对于诊断，可能需要将PDM与其他标题（第2层、第3层等）一起使用。例如，如果PDM由查看数据包捕获的技术人员（或工具）使用，在数据包捕获中，他们可以使用第2层报头、IP报头（v6或v4）、TCP报头、UDP报头、ICMP报头、SCTP报头或其他报头。所有的信息都将被放在一起查看，以理解数据包流。必要时，技术人员或处理工具可以分析、报告或忽略来自PDM的数据。
For an example of how PDM can help with TCP retransmission problems, please look at Appendix C.
有关PDM如何帮助解决TCP重传问题的示例，请参阅附录C。
When SCALEDTLR or SCALEDTLS is used, it means that the description of the processing applies equally to SCALEDTLR and SCALEDTLS.
当使用SCALEDTLR或SCALEDTLS时，这意味着处理的描述同样适用于SCALEDTLR和SCALEDTLS。
The time counter in a CPU is a binary whole number representing a number of milliseconds (msec), microseconds (usec), or even picoseconds (psec). Representing one of these values as attoseconds (asec) means multiplying by 10 raised to some exponent. Refer to this table of equalities:
CPU中的时间计数器是一个二进制整数，表示毫秒（msec）、微秒（usec）甚至皮秒（psec）的数量。将这些值中的一个表示为阿秒（asec）意味着乘以10并提升到某个指数。请参阅此等式表：
Base value = # of sec = # of asec 1000s of asec
--------------- ------------- ------------- -------------
1 second 1 sec 10**18 asec 1000**6 asec
1 millisecond 10**-3 sec 10**15 asec 1000**5 asec
1 microsecond 10**-6 sec 10**12 asec 1000**4 asec
1 nanosecond 10**-9 sec 10**9 asec 1000**3 asec
1 picosecond 10**-12 sec 10**6 asec 1000**2 asec
1 femtosecond 10**-15 sec 10**3 asec 1000**1 asec
Base value = # of sec = # of asec 1000s of asec
--------------- ------------- ------------- -------------
1 second 1 sec 10**18 asec 1000**6 asec
1 millisecond 10**-3 sec 10**15 asec 1000**5 asec
1 microsecond 10**-6 sec 10**12 asec 1000**4 asec
1 nanosecond 10**-9 sec 10**9 asec 1000**3 asec
1 picosecond 10**-12 sec 10**6 asec 1000**2 asec
1 femtosecond 10**-15 sec 10**3 asec 1000**1 asec
For example, if you have a time differential expressed in microseconds, since each microsecond is 10**12 asec, you would multiply your time value by 10**12 to obtain the number of attoseconds. If your time differential is expressed in nanoseconds, you would multiply by 10**9 to get the number of attoseconds.
例如，如果您有以微秒表示的时间差，因为每微秒是10**12 asec，所以您将时间值乘以10**12以获得阿秒数。如果时间差以纳秒表示，则乘以10**9得到阿秒数。
The result is a binary value that will need to be shortened by a number of bits so it will fit into the 16-bit PDM delta field.
结果是一个二进制值，该值需要缩短若干位，以便适合16位PDM增量字段。
The next step is to divide by 2 until the value is contained in just 16 significant bits. The exponent of the value in the last column of the table is useful here; the initial scaling factor is that exponent multiplied by 10. This is the minimum number of low-order bits to be shifted out or discarded. It represents dividing the time value by 1024 raised to that exponent.
下一步是除以2，直到值仅包含在16个有效位中。表的最后一列中的值的指数在这里很有用；初始比例因子是该指数乘以10。这是要移出或丢弃的最低低位数。它表示将时间值除以提升到该指数的1024。
The resulting value may still be too large to fit into 16 bits but can be normalized by shifting out more bits (dividing by 2) until the value fits into the 16-bit delta field. The number of extra bits shifted out is then added to the scaling factor. The scaling factor -- the total number of low-order bits dropped -- is the SCALEDTLR or SCALEDTLS value.
结果值可能仍然太大，无法装入16位，但可以通过移出更多位（除以2）进行归一化，直到值装入16位增量字段。然后将移出的额外位数添加到比例因子中。比例因子（丢弃的低位总数）是SCALEDTLR或SCALEDTLS值。
For example, say an application has these start and finish timer values (hexadecimal values, in microseconds):
例如，假设应用程序具有以下开始和结束计时器值（十六进制值，以微秒为单位）：
Finish: 27C849234 usec (02:57:58.997556)
-Start: 27C83F696 usec (02:57:58.957718)
========== ============== ==========================
Difference 9B9E usec 0.039838 sec or 39838 usec
Finish: 27C849234 usec (02:57:58.997556)
-Start: 27C83F696 usec (02:57:58.957718)
========== ============== ==========================
Difference 9B9E usec 0.039838 sec or 39838 usec
To convert this differential value to binary attoseconds, multiply the number of microseconds by 10**12. Divide by 1024**4, or simply discard 40 bits from the right. The result is 36232, or 8D88 in hex, with a scaling factor or SCALEDTLR/SCALEDTLS value of 40.
要将此差值转换为二进制阿秒，请将微秒数乘以10**12。除以1024**4，或仅从右侧丢弃40位。结果是36232或8D88（十六进制），比例因子或SCALEDTLR/SCALEDTLS值为40。
For another example, presume the time differential is larger, say 32.311072 seconds, which is 32311072 usec. Each microsecond is 10**12 asec, so multiply by 10**12, giving the hexadecimal value 1C067FCCAE8120000. Using the initial scaling factor of 40, drop the last 10 characters (40 bits) from that string, giving 1C067FC. This will not fit into a delta field, as it is 25 bits long. Shifting the value to the right another 9 bits results in a delta value of E033, with a resulting scaling factor of 49.
例如，假设时间差较大，例如32.311072秒，即32311072 usec。每微秒是10**12 asec，因此乘以10**12，得到十六进制值1C067FCCAE8120000。使用初始比例因子40，从该字符串中删除最后10个字符（40位），得到1C067FC。这不适合delta字段，因为它是25位长的。将该值向右再移动9位，得到的增量值为E033，得到的比例因子为49。
When the time-differential value is a small number, regardless of the time unit, the exponent trick given above is not useful in determining the proper scaling value. For example, if the time differential is 3 seconds and you want to convert that directly, you would follow this path:
当时间差数值很小时，不管时间单位是什么，上面给出的指数技巧在确定适当的缩放值时是没有用的。例如，如果时间差为3秒，并且您希望直接转换，则应遵循以下路径：
3 seconds = 3*10**18 asec (decimal)
= 29A2241AF62C0000 asec (hexadecimal)
3 seconds = 3*10**18 asec (decimal)
= 29A2241AF62C0000 asec (hexadecimal)
If you just truncate the last 60 bits, you end up with a delta value of 2 and a scaling factor of 60, when what you really wanted was a delta value with more significant digits. The most precision with which you can store this value in 16 bits is A688, with a scaling factor of 46.
如果只截断最后60位，则最终的增量值为2，比例因子为60，而实际需要的是具有更高有效位数的增量值。以16位存储此值的最高精度是A688，比例因子为46。
There are two considerations to be taken into account with this representation of a time differential. The first is whether there are any limitations on the maximum or minimum time differential that can be expressed using the method of a delta value and a scaling factor. The second is the amount of imprecision introduced by this method.
在表示时间差时，需要考虑两个因素。第一个问题是，使用增量值和比例因子的方法表示的最大或最小时间差是否存在任何限制。第二是这种方法引入的不精确性。
The DELTATLS and DELTATLR fields store only the 16 most significant bits of the time-differential value. Thus, the range, excluding the scaling factor, is from 0 to 65535, or a maximum of 2**16 - 1. This method is further described in [TCPM].
DELTATLS和DELTATLR字段仅存储时间差数值的16个最高有效位。因此，不包括比例因子的范围为0到65535，或最大值为2**16-1。[TCPM]中进一步描述了该方法。
The actual magnitude of the time differential is determined by the scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers, so the scaling factor ranges from 0 to 255. The smallest number that can be represented would have a value of 1 in the delta field and a value of 0 in the associated scale field. This is the representation for 1 attosecond. Clearly, this allows PDM to measure extremely small time differentials.
时间差的实际大小由比例因子确定。SCALEDTLR和ScaleDTL是8位无符号整数，因此缩放因子的范围为0到255。可以表示的最小数字在增量字段中的值为1，在关联的比例字段中的值为0。这是1阿秒的表示。显然，这允许PDM测量极小的时间差。
On the other end of the scale, the maximum delta value is 65535, or FFFF in hexadecimal. If the maximum scale value of 255 is used, the time differential represented is 65535*2**255, which is over 3*10**55 years -- essentially, forever. So, there appears to be no real limitation to the time differential that can be represented.
在刻度的另一端，最大增量值为65535，或十六进制的FFFF。如果使用最大刻度值255，则表示的时间差为65535*2**255，即超过3*10**55年——基本上是永远的。因此，对可以表示的时间差似乎没有真正的限制。
As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned integers, any time that the precision is greater than those 16 bits, there will be truncation of the trailing bits, with an accompanying loss of precision in the value.
由于PDM将DELTATLR和DELTATLS值指定为16位无符号整数，因此每当精度大于这16位时，将截断尾随位，并伴随该值的精度损失。
Any time-differential value smaller than 65536 asec can be stored exactly in DELTATLR or DELTATLS, because the representation of this value requires at most 16 bits.
任何小于65536 asec的时间差分值都可以准确地存储在DELTATLR或DELTATLS中，因为此值的表示最多需要16位。
Since the time-differential values in PDM are measured in attoseconds, the range of values that would be truncated to the same encoded value is 2**((Scale) - 1) asec.
由于PDM中的时间差值是以阿秒为单位测量的，因此将被截断为相同编码值的值范围为2**（（刻度）-1）asec。
For example, the smallest time differential that would be truncated to fit into a delta field is
例如，将被截断以适合增量字段的最小时间差为
1 0000 0000 0000 0000 = 65536 asec
1 0000=65536 asec
This value would be encoded as a delta value of 8000 (hexadecimal) with a scaling factor of 1. The value
该值将被编码为8000（十六进制）的增量值，比例因子为1。价值
1 0000 0000 0000 0001 = 65537 asec
1 0000 0001=65537 asec
would also be encoded as a delta value of 8000 with a scaling factor of 1. This actually is the largest value that would be truncated to that same encoded value. When the scale value is 1, the value range is calculated as 2**1 - 1, or 1 asec, which you can see is the difference between these minimum and maximum values.
也将被编码为8000的增量值，比例因子为1。这实际上是将被截断为相同编码值的最大值。当比例值为1时，值范围计算为2**1-1或1 asec，您可以看到这些最小值和最大值之间的差异。
The scaling factor is defined as the number of low-order bits truncated to reduce the size of the resulting value so it fits into a 16-bit delta field. If, for example, you had to truncate 12 bits, the loss of precision would depend on the bits you truncated. The range of these values would be
比例因子定义为被截断的低阶位的数量，以减少结果值的大小，从而使其适合16位增量字段。例如，如果必须截断12位，则精度损失将取决于截断的位。这些值的范围是
0000 0000 0000 = 0 asec
0000=0 asec
to
到
1111 1111 1111 = 4095 asec
1111111111=4095 asec
So, the minimum loss of precision would be 0 asec, where the delta value exactly represents the time differential, and the maximum loss of precision would be 4095 asec. As stated above, the scaling factor of 12 means that the maximum loss of precision is 2**12 - 1 asec, or 4095 asec.
因此，最小精度损失为0 asec，其中delta值正好代表时间差，最大精度损失为4095 asec。如上所述，比例因子12表示最大精度损失为2**12-1 asec或4095 asec。
Compare this loss of precision to the actual time differential. The range of actual time-differential values that would incur this loss of precision is from
将此精度损失与实际时间差进行比较。导致精度损失的实际时间差数值范围为
1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec
1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec
to
到
1111 1111 1111 1111 1111 1111 1111 = 2**28 - 1 asec or 268435455 asec
1111 1111 1111 1111 1111 1111 1111 = 2**28 - 1 asec or 268435455 asec
Granted, these are small values, but the point is that any value between these two values will have a maximum loss of precision of 4095 asec, or about 0.00305% for the first value, as encoded, and at most 0.001526% for the second. These maximum-loss percentages are consistent for all scaling values.
诚然，这些值都很小，但关键是这两个值之间的任何值都会有4095 asec的最大精度损失，即编码后的第一个值的精度损失约为0.00305%，第二个值的精度损失最多为0.001526%。这些最大损失百分比对于所有缩放值都是一致的。
Below is a sample simple flow for PDM with one packet sent from Host A and one packet received by Host B. PDM does not require time synchronization between Host A and Host B. The calculations to derive meaningful metrics for network diagnostics are shown below each packet sent or received.
下面是PDM的简单流程示例，其中一个数据包从主机a发送，另一个数据包由主机B接收。PDM不需要主机a和主机B之间的时间同步。用于推导网络诊断的有意义指标的计算显示在发送或接收的每个数据包的下方。
Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM.
数据包1从主机A发送到主机B。主机A的时间最初设置为上午10:00。
The time and packet sequence number are saved by the sender internally. The packet sequence number and delta times are sent in the packet.
时间和数据包序列号由发送方在内部保存。数据包序列号和增量时间在数据包中发送。
Packet 1
包1
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
产品数据管理内容：
PSNTP : Packet Sequence Number This Packet: 25
PSNLR : Packet Sequence Number Last Received: -
DELTATLR : Delta Time Last Received: -
SCALEDTLR: Scale of Delta Time Last Received: 0
DELTATLS : Delta Time Last Sent: -
SCALEDTLS: Scale of Delta Time Last Sent: 0
PSNTP : Packet Sequence Number This Packet: 25
PSNLR : Packet Sequence Number Last Received: -
DELTATLR : Delta Time Last Received: -
SCALEDTLR: Scale of Delta Time Last Received: 0
DELTATLS : Delta Time Last Sent: -
SCALEDTLS: Scale of Delta Time Last Sent: 0
Internally, within the sender, Host A, it must keep:
在发送方（主机A）内部，它必须保持：
Packet Sequence Number of the last packet sent: 25
Time the last packet was sent: 10:00:00
Packet Sequence Number of the last packet sent: 25
Time the last packet was sent: 10:00:00
Note: The initial PSNTP from Host A starts at a random number -- in this case, 25. The time in these examples is shown in seconds for the sake of simplicity.
注意：来自主机A的初始PSNTP以随机数开始——在本例中为25。为了简单起见，这些示例中的时间以秒为单位显示。
Packet 1 is received at Host B. Its time is set to 1 hour later than Host A -- in this case, 11:00AM.
数据包1在主机B接收。其时间设置为比主机A晚1小时——在本例中为上午11:00。
Internally, within the receiver, Host B, it must note the following:
在接收器（主机B）内部，必须注意以下事项：
Packet Sequence Number of the last packet received: 25
Time the last packet was received : 11:00:03
Packet Sequence Number of the last packet received: 25
Time the last packet was received : 11:00:03
Note: This timestamp is in Host B time. It has nothing whatsoever to do with Host A time. The packet sequence number of the last packet received will become PSNLR, which will be sent out in the packet sent by Host B in the next step. The timestamp of the packet last received (as noted above) will be used as input to calculate the DELTATLR value to be sent out in the packet sent by Host B in the next step.
注意：此时间戳为主机B时间。这和主人一段时间没有任何关系。最后接收到的数据包的数据包序列号将变为PSNLR，在下一步主机B发送的数据包中发送PSNLR。最后接收到的分组的时间戳（如上所述）将用作输入，以计算在下一步骤中主机B发送的分组中要发送的DELTATLR值。
Packet 2 is sent by Host B to Host A. Note that the initial packet sequence number (PSNTP) from Host B starts at a random number -- in this case, 12. Before sending the packet, Host B does a calculation of deltas. Since Host B knows when it is sending the packet and it knows when it received the previous packet, it can do the following calculation:
数据包2由主机B发送到主机A。请注意，来自主机B的初始数据包序列号（PSNTP）以随机数开始——在本例中为12。在发送数据包之前，主机B进行增量计算。由于主机B知道它何时发送数据包，并且知道它何时接收到上一个数据包，因此它可以执行以下计算：
DELTATLR = send time (packet 2) - receive time (packet 1)
DELTATLR=发送时间（数据包2）-接收时间（数据包1）
Note: Both the send time and the receive time are saved internally in Host B. They do not travel in the packet. Only the change in values (delta) is in the packet. This is the DELTATLR value.
注意：发送时间和接收时间都保存在主机B内部。它们不在数据包中传输。数据包中只有值的变化（增量）。这是DELTATLR值。
Assume that within Host B we have the following:
假设在主机B中，我们有以下内容：
Packet Sequence Number of the last packet received: 25
Time the last packet was received: 11:00:03
Packet Sequence Number of this packet: 12
Time this packet is being sent: 11:00:07
Packet Sequence Number of the last packet received: 25
Time the last packet was received: 11:00:03
Packet Sequence Number of this packet: 12
Time this packet is being sent: 11:00:07
A delta value to be sent out in the packet can now be calculated. DELTATLR becomes:
现在可以计算数据包中要发送的增量值。DELTATLR变为：
4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec
4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec
This is the derived metric: server delay. The time scaling factors must be converted; in this case, the time differential is DE0B, and the scaling factor is 2E, or 46 in decimal. Then, these values, along with the packet sequence numbers, will be sent to Host A as follows:
这是派生的度量：服务器延迟。必须转换时间比例因子；在这种情况下，时间差为DE0B，比例因子为2E，或十进制为46。然后，这些值以及数据包序列号将被发送到主机A，如下所示：
Packet 2
包2
+----------+ +----------+
| | | |
| Host | <---------- | Host |
| A | | B |
| | | |
+----------+ +----------+
+----------+ +----------+
| | | |
| Host | <---------- | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
产品数据管理内容：
PSNTP : Packet Sequence Number This Packet: 12
PSNLR : Packet Sequence Number Last Received: 25
DELTATLR : Delta Time Last Received: DE0B (4 seconds)
SCALEDTLR: Scale of Delta Time Last Received: 2E (46 decimal)
DELTATLS : Delta Time Last Sent: -
SCALEDTLS: Scale of Delta Time Last Sent: 0
PSNTP : Packet Sequence Number This Packet: 12
PSNLR : Packet Sequence Number Last Received: 25
DELTATLR : Delta Time Last Received: DE0B (4 seconds)
SCALEDTLR: Scale of Delta Time Last Received: 2E (46 decimal)
DELTATLS : Delta Time Last Sent: -
SCALEDTLS: Scale of Delta Time Last Sent: 0
The metric left to be calculated is the round-trip delay. This will be calculated by Host A when it receives packet 2.
剩下要计算的度量是往返延迟。这将由主机A在接收数据包2时计算。
Packet 2 is received at Host A. Remember that its time is set to 1 hour earlier than Host B. Internally, it must note the following:
数据包2在主机A接收。请记住，其时间设置为比主机B早1小时。在内部，它必须注意以下事项：
Packet Sequence Number of the last packet received: 12
Time the last packet was received : 10:00:12
Packet Sequence Number of the last packet received: 12
Time the last packet was received : 10:00:12
Note: This timestamp is in Host A time. It has nothing whatsoever to do with Host B time.
注意：此时间戳在主机A时间内。这与主持人B的时间没有任何关系。
So, Host A can now calculate total end-to-end time. That is:
因此，主机A现在可以计算总的端到端时间。即:
End-to-End Time = Time Last Received - Time Last Sent
端到端时间=上次接收的时间-上次发送的时间
For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was received by Host A at 10:00:12, so:
例如，包25由主机A在10:00:00发送。主机A在10:00:12收到数据包12，因此：
End-to-End time = 10:00:12 - 10:00:00 or 12 (server and network round-trip delay combined).
端到端时间=10:00:12-10:00:00或12（服务器和网络往返延迟组合）。
This time may also be called "total overall Round-Trip Time (RTT)", which includes network RTT and host response time.
此时间也可称为“总往返时间（RTT）”，包括网络RTT和主机响应时间。
We will call this derived metric "Delta Time Last Sent" (DELTATLS).
我们将此派生度量称为“上次发送的增量时间”（DELTATLS）。
Round-trip delay can now be calculated. The formula is:
现在可以计算往返延迟。公式是：
Round-trip delay = (Delta Time Last Sent - Delta Time Last Received)
往返延迟=（上次发送的增量时间-上次接收的增量时间）
Or:
或：
Round-trip delay = 12 - 4 or 8
往返延迟=12-4或8
At this point, the only problem is that all metrics are in Host A only and not exposed in a packet. To do that, we need a third packet.
在这一点上，唯一的问题是所有度量都只在主机A中，而不是在数据包中公开。要做到这一点，我们需要第三包。
Note: This simple example assumes one send and one receive. That is done only for purposes of explaining the function of PDM. In cases where there are multiple packets returned, one would take the time in the last packet in the sequence. The calculations of such timings and intelligent processing are the function of post-processing of the data.
注意：这个简单的示例假设一个发送和一个接收。这样做只是为了解释PDM的功能。在返回多个数据包的情况下，一个数据包将占用序列中最后一个数据包的时间。此类计时的计算和智能处理是数据后处理的功能。
Packet 3 is sent from Host A to Host B.
数据包3从主机A发送到主机B。
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
产品数据管理内容：
PSNTP : Packet Sequence Number This Packet: 26
PSNLR : Packet Sequence Number Last Received: 12
DELTATLR : Delta Time Last Received: 0
SCALEDTLS: Scale of Delta Time Last Received 0
DELTATLS : Delta Time Last Sent: A688 (scaled value)
SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal)
PSNTP : Packet Sequence Number This Packet: 26
PSNLR : Packet Sequence Number Last Received: 12
DELTATLR : Delta Time Last Received: 0
SCALEDTLS: Scale of Delta Time Last Received 0
DELTATLS : Delta Time Last Sent: A688 (scaled value)
SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal)
To calculate two-way delay, any packet-capture device may look at these packets and do what is necessary.
为了计算双向延迟，任何包捕获设备都可以查看这些包并执行必要的操作。
What has been discussed so far is a simple flow with one packet sent and one returned. Let's look at how PDM may be useful in other types of flows.
到目前为止，我们讨论的是一个简单的流，一个包被发送，一个包被返回。让我们看看PDM在其他类型的流中是如何有用的。
The flow on a particular session may not be a send-receive paradigm. Let us consider some other situations. In the case of a one-way flow, one might see the following.
特定会话上的流可能不是发送-接收范例。让我们考虑一些其他的情况。在单向流的情况下，可能会看到以下内容。
Note: The time is expressed in generic units for simplicity. That is, these values do not represent a number of attoseconds, microseconds, or any other real units of time.
注：为简单起见，时间以通用单位表示。也就是说，这些值并不表示阿秒、微秒或任何其他实际时间单位。
Packet Sender PSN PSN Delta Time Delta Time
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Server 3 0 0 12
4 Server 4 0 0 20
Packet Sender PSN PSN Delta Time Delta Time
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Server 3 0 0 12
4 Server 4 0 0 20
What does this mean, and how is it useful?
这意味着什么？它如何有用？
In a one-way flow, only the Delta Time Last Sent will be seen as used. Recall that Delta Time Last Sent is the difference between the send of one packet from a device and the next. This is a measure of throughput for the sender -- according to the sender's point of view. That is, it is a measure of how fast the application itself (with stack time included) is able to send packets.
在单向流中，只有上次发送的增量时间才会被视为已使用。回想一下，上次发送的增量时间是设备发送一个数据包和下一个数据包之间的差值。根据发送方的观点，这是对发送方吞吐量的度量。也就是说，它是应用程序本身（包括堆栈时间）能够发送数据包的速度的度量。
How might this be useful? If one is having a performance issue at the client and sees that packet 2, for example, is sent after 5 time units from the server but takes 10 times that long to arrive at the destination, then one may safely conclude that there are delays in the path, other than at the server, that may be causing the delivery issue for that packet. Such delays may include the network links, middleboxes, etc.
这有什么用处？如果一个人在客户端出现性能问题，并且看到包2（例如）在5个时间单位之后从服务器发送，但到达目的地的时间是该时间单位的10倍，那么他可以安全地得出结论，在路径中存在延迟，而不是在服务器上，这可能导致该包的交付问题。此类延迟可能包括网络链路、中间盒等。
True one-way traffic is quite rare. What people often mean by "one-way" traffic is an application such as FTP where a group of packets (for example, a TCP window size worth) is sent and the sender then waits for acknowledgment. This type of flow would actually fall into the "multiple-send" traffic model.
真正的单向交通是相当罕见的。人们通常所说的“单向”流量是指一个应用程序，如FTP，其中发送一组数据包（例如，TCP窗口大小），然后发送方等待确认。这种类型的流量实际上属于“多发送”流量模型。
Assume that two packets are sent from the server and then an ACK is sent from the client. For example, a TCP flow will do this, per RFC 1122 [RFC1122], Section 4.2.3. Packets 1 and 2 are sent from the server, and then an ACK is sent from the client. Packet 4 starts a second sequence from the server.
假设从服务器发送两个数据包，然后从客户端发送ACK。例如，根据RFC 1122[RFC1122]，第4.2.3节，TCP流将执行此操作。数据包1和2从服务器发送，然后从客户端发送ACK。数据包4从服务器开始第二个序列。
Packet Sender PSN PSN Delta Time Delta Time
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Client 1 2 20 0
4 Server 3 1 10 15
Packet Sender PSN PSN Delta Time Delta Time
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Client 1 2 20 0
4 Server 3 1 10 15
How might this be used?
这个怎么用？
Notice that in packet 3, the client has a Delta Time Last Received value of 20. Recall that:
注意，在数据包3中，客户机的Delta Time Last Received值为20。回顾：
DELTATLR = send time (packet 3) - receive time (packet 2)
DELTATLR=发送时间（数据包3）-接收时间（数据包2）
So, what does one know now? In this case, Delta Time Last Received is the processing time for the client to send the next packet.
那么，我们现在知道了什么？在这种情况下，上次接收的增量时间是客户端发送下一个数据包的处理时间。
How to interpret this depends on what is actually being sent. Remember that PDM is not being used in isolation; rather, it is used to supplement the fields found in other headers. Let's take two examples:
如何解释这一点取决于实际发送的内容。请记住，PDM不是单独使用的；相反，它用于补充在其他标头中找到的字段。让我们举两个例子：
1. The client is sending a standalone TCP ACK. One would find this by looking at the payload length in the IPv6 header and the TCP Acknowledgment field in the TCP header. So, in this case, the client is taking 20 time units to send back the ACK. This may or may not be interesting.
1. 客户端正在发送独立的TCP确认。可以通过查看IPv6标头中的有效负载长度和TCP标头中的TCP确认字段来发现这一点。因此，在这种情况下，客户端需要20个时间单位才能发回ACK。这可能有趣，也可能不有趣。
2. The client is sending data with the packet. Again, one would find this by looking at the payload length in the IPv6 header and the TCP Acknowledgment field in the TCP header. So, in this case, the client is taking 20 time units to send back data. This may represent "User Think Time". Again, this may or may not be interesting in isolation. But if there is a performance problem receiving data at the server, then, taken in conjunction with RTT or other packet timing information, this information may be quite interesting.
2. 客户端正在随数据包发送数据。同样，可以通过查看IPv6报头中的有效负载长度和TCP报头中的TCP确认字段来发现这一点。因此，在这种情况下，客户端需要20个时间单位才能发送回数据。这可能代表“用户思考时间”。同样，这可能是有趣的，也可能不是孤立的。但是，如果在服务器上接收数据时出现性能问题，那么，结合RTT或其他数据包定时信息，这些信息可能非常有趣。
Of course, one also needs to look at the PSN Last Received field to make sure of the interpretation of this data -- that is, to make sure that the Delta Time Last Received corresponds to the packet of interest.
当然，我们还需要查看PSN Last Received字段，以确保对该数据的解释——也就是说，确保上次接收的增量时间对应于感兴趣的数据包。
The benefits of PDM are that such information is now available in a uniform manner for all applications and all protocols without extensive changes required to applications.
PDM的好处是，这些信息现在以统一的方式可用于所有应用程序和所有协议，而无需对应用程序进行大量更改。
Let us now look at a case of how PDM may be able to help in a case of TCP retransmission and add to the information that is sent in the TCP header.
现在让我们来看一个例子，说明PDM如何能够在TCP重传的情况下提供帮助，并添加到TCP报头中发送的信息中。
Assume that three packets are sent with each send from the server.
假设服务器每次发送时发送三个数据包。
From the server, this is what is seen:
从服务器上可以看到：
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 2 0 0 5 223 100
3 Server 3 0 0 5 333 100
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 2 0 0 5 223 100
3 Server 3 0 0 5 333 100
The client, however, does not receive all the packets. From the client, this is what is seen for the packets sent from the server:
然而，客户端并没有接收到所有的数据包。从客户端可以看到从服务器发送的数据包：
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 3 0 0 5 333 100
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 3 0 0 5 333 100
Let's assume that the server now retransmits the packet. (Obviously, a duplicate acknowledgment sequence for fast retransmit or a retransmit timeout would occur. To illustrate the point, these packets are being left out.)
让我们假设服务器现在重新传输数据包。（显然，快速重传的重复确认序列或重传超时会发生。为了说明这一点，这些数据包被忽略了。）
So, if a TCP retransmission is done, then from the client, this is what is seen for the packets sent from the server:
因此，如果TCP重新传输完成，那么从客户机可以看到从服务器发送的数据包：
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 4 0 0 30 223 100
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 4 0 0 30 223 100
The server has resent the old packet 2 with a TCP sequence number of 223. The retransmitted packet now has a PSN This Packet value of 4.
服务器已重新发送TCP序列号为223的旧数据包2。重新传输的数据包现在的PSN This数据包值为4。
The Delta Time Last Sent is 30 -- in other words, the time between sending the packet with a PSN of 3 and this current packet.
上次发送的增量时间是30——换句话说，发送PSN为3的数据包和当前数据包之间的时间。
Let's say that packet 4 is lost again. Then, after some amount of time (RTO), the packet with a TCP sequence number of 223 is resent.
假设第4包又丢失了。然后，经过一段时间（RTO），重新发送TCP序列号为223的数据包。
From the client, this is what is seen for the packets sent from the server:
从客户端可以看到从服务器发送的数据包：
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
====================================================================
1 Server 5 0 0 60 223 100
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
====================================================================
1 Server 5 0 0 60 223 100
If this packet now arrives at the destination, one has a very good idea that packets exist that are being sent from the server as retransmissions and not arriving at the client. This is because the PSN of the resent packet from the server is 5 rather than 4. If we had used the TCP sequence number alone, we would never have seen this situation. The TCP sequence number in all situations is 223.
如果这个数据包现在到达目的地，我们就可以很好地理解存在着作为重传从服务器发送而没有到达客户端的数据包。这是因为来自服务器的重新发送数据包的PSN是5而不是4。如果我们单独使用TCP序列号，我们将永远不会看到这种情况。所有情况下的TCP序列号均为223。
This situation would be experienced by the user of the application (the human being actually sitting somewhere) as "hangs" or long delays between packets. On large networks, to diagnose problems such as these where packets are lost somewhere on the network, one has to take multiple traces to find out exactly where.
应用程序的用户（实际坐在某处的人）可能会遇到这种情况，即数据包之间的“挂起”或长时间延迟。在大型网络上，要诊断诸如数据包在网络某处丢失之类的问题，必须进行多次跟踪，以查明确切的位置。
The first thing to do is to start with doing a trace at the client and the server, so that we can see if the server sent a particular packet and the client received it. If the client did not receive it, then we start tracking back to trace points at the router right after the server and the router right before the client. Did they get these packets that the server has sent? This is a time-consuming activity.
首先要做的是在客户端和服务器上进行跟踪，这样我们就可以看到服务器是否发送了一个特定的数据包，而客户端是否收到了它。如果客户端没有收到它，那么我们就开始跟踪服务器后面的路由器和客户端前面的路由器上的跟踪点。他们收到服务器发送的数据包了吗？这是一项耗时的活动。
With PDM, we can speed up the diagnostic time because we may be able to use only the trace taken at the client to see what the server is sending.
使用PDM，我们可以加快诊断时间，因为我们可能只能使用在客户端进行的跟踪来查看服务器发送的内容。
One might wonder about the potential overhead of PDM. First, PDM is entirely optional. That is, a site may choose to implement PDM or not, as they wish. If they are happy with the costs of PDM versus the benefits, then the choice should be theirs.
人们可能想知道PDM的潜在开销。首先，PDM是完全可选的。也就是说，站点可以根据自己的意愿选择是否实施PDM。如果他们对PDM的成本和收益感到满意，那么他们应该做出选择。
Below is a table outlining the potential overhead in terms of additional time to deliver the response to the end user for various assumed RTTs:
下表概述了针对各种假定RTT向最终用户提供响应的额外时间方面的潜在开销：
Bytes RTT Bytes Bytes New Overhead
in Packet Per Millisec in PDM RTT
====================================================================
1000 1000 milli 1 16 1016.000 16.000 milli
1000 100 milli 10 16 101.600 1.600 milli
1000 10 milli 100 16 10.160 0.160 milli
1000 1 milli 1000 16 1.016 0.016 milli
Bytes RTT Bytes Bytes New Overhead
in Packet Per Millisec in PDM RTT
====================================================================
1000 1000 milli 1 16 1016.000 16.000 milli
1000 100 milli 10 16 101.600 1.600 milli
1000 10 milli 100 16 10.160 0.160 milli
1000 1 milli 1000 16 1.016 0.016 milli
Below are two examples of actual RTTs for packets traversing large enterprise networks.
下面是两个用于穿越大型企业网络的数据包的实际RTT示例。
The first example is for packets going to multiple business partners:
第一个示例是发送给多个业务合作伙伴的数据包：
Bytes RTT Bytes Bytes New Overhead
in Packet Per Millisec in PDM RTT
====================================================================
1000 17 milli 58 16 17.360 0.360 milli
Bytes RTT Bytes Bytes New Overhead
in Packet Per Millisec in PDM RTT
====================================================================
1000 17 milli 58 16 17.360 0.360 milli
The second example is for packets at a large enterprise customer within a data center. Notice that the scale is now in microseconds rather than milliseconds:
第二个示例是数据中心内大型企业客户的数据包。请注意，比例现在以微秒而不是毫秒为单位：
Bytes RTT Bytes Bytes New Overhead
in Packet Per Microsec in PDM RTT
====================================================================
1000 20 micro 50 16 20.320 0.320 micro
Bytes RTT Bytes Bytes New Overhead
in Packet Per Microsec in PDM RTT
====================================================================
1000 20 micro 50 16 20.320 0.320 micro
As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM. Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal.
与其他诊断工具（如数据包跟踪）一样，创建和处理PDM需要一定的处理时间。由于PDM是轻量级的（只有几个变量），我们希望处理时间最少。
Acknowledgments
致谢
The authors would like to thank Keven Haining, Al Morton, Brian Trammell, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick Troth for their comments and assistance. We would also like to thank Tero Kivinen and Jouni Korhonen for their detailed and perceptive reviews.
作者要感谢Keven Haining、Al Morton、Brian Trammell、David Boyes、Bill Jouris、Richard Scheffenegger和Rick Troth的评论和帮助。我们还要感谢Tero Kivinen和Jouni Korhonen的详细和深刻的评论。
Authors' Addresses
作者地址
Nalini Elkins Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States of America
Nalini Elkins Inside Products，Inc.美国加利福尼亚州卡梅尔河谷上环36A，邮编93924
Phone: +1 831 659 8360
Email: nalini.elkins@insidethestack.com
URI: http://www.insidethestack.com
Phone: +1 831 659 8360
Email: nalini.elkins@insidethestack.com
URI: http://www.insidethestack.com
Robert M. Hamilton Chemical Abstracts Service A Division of the American Chemical Society 2540 Olentangy River Road Columbus, Ohio 43202 United States of America
罗伯特·M·汉密尔顿化学文摘社美国化学学会分部，美国俄亥俄州哥伦布市奥兰坦基河路2540号，邮编：43202
Phone: +1 614 447 3600 x2517
Email: rhamilton@cas.org
URI: http://www.cas.org
Phone: +1 614 447 3600 x2517
Email: rhamilton@cas.org
URI: http://www.cas.org
Michael S. Ackermann Blue Cross Blue Shield of Michigan P.O. Box 2888 Detroit, Michigan 48231 United States of America
美国密歇根州底特律市密歇根蓝十字蓝盾邮政信箱2888号，邮编：48231
Phone: +1 310 460 4080
Email: mackermann@bcbsm.com
URI: http://www.bcbsm.com
Phone: +1 310 460 4080
Email: mackermann@bcbsm.com
URI: http://www.bcbsm.com