Network Working Group A. Morton
Request for Comments: 4737 L. Ciavattone
Category: Standards Track G. Ramachandran
AT&T Labs
S. Shalunov
Internet2
J. Perser
Veriwave
November 2006
Network Working Group A. Morton
Request for Comments: 4737 L. Ciavattone
Category: Standards Track G. Ramachandran
AT&T Labs
S. Shalunov
Internet2
J. Perser
Veriwave
November 2006
Packet Reordering Metrics
包重排序度量
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An appendix gives extended definitions for evaluating order with packet fragmentation.
此备忘录定义了评估网络是否在分组基础上维持分组顺序的指标。它提供了新度量的动机，并讨论了度量问题，包括所有度量所需的上下文信息。备忘录首先定义了重新排序的单例，然后将其用作样本度量的基础，以量化网络表征或接收器设计中几个有用维度的重新排序程度。其他指标量化了重新排序的频率和单独事件之间的距离。然后，我们定义了一个用于评估TCP重新排序影响的度量。包括使用各种样本度量进行评估的几个示例。附录给出了使用数据包碎片评估订单的扩展定义。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Motivation .................................................4
1.2. Goals and Objectives .......................................5
1.3. Required Context for All Reordering Metrics ................6
2. Conventions Used in this Document ...............................7
3. A Reordered Packet Singleton Metric .............................7
3.1. Metric Name ................................................8
3.2. Metric Parameters ..........................................8
3.3. Definition .................................................8
3.4. Sequence Discontinuity Definition ..........................9
3.5. Evaluation of Reordering in Dimensions of Time or Bytes ...10
3.6. Discussion ................................................10
4. Sample Metrics .................................................11
4.1. Reordered Packet Ratio ....................................11
4.1.1. Metric Name ........................................11
4.1.2. Metric Parameters ..................................11
4.1.3. Definition .........................................12
4.1.4. Discussion .........................................12
4.2. Reordering Extent .........................................12
4.2.1. Metric Name ........................................12
4.2.2. Notation and Metric Parameters .....................12
4.2.3. Definition .........................................13
4.2.4. Discussion .........................................13
4.3. Reordering Late Time Offset ...............................14
4.3.1. Metric Name ........................................14
4.3.2. Metric Parameters ..................................14
4.3.3. Definition .........................................15
4.3.4. Discussion .........................................15
4.4. Reordering Byte Offset ....................................16
4.4.1. Metric Name ........................................16
4.4.2. Metric Parameters ..................................16
4.4.3. Definition .........................................16
4.4.4. Discussion .........................................17
4.5. Gaps between Multiple Reordering Discontinuities ..........17
4.5.1. Metric Names .......................................17
4.5.2. Parameters .........................................17
4.5.3. Definition of Reordering Discontinuity .............17
4.5.4. Definition of Reordering Gap .......................18
4.5.5. Discussion .........................................18
4.6. Reordering-Free Runs ......................................19
4.6.1. Metric Names .......................................19
4.6.2. Parameters .........................................19
4.6.3. Definition .........................................19
4.6.4. Discussion and Illustration ........................20
1. Introduction ....................................................4
1.1. Motivation .................................................4
1.2. Goals and Objectives .......................................5
1.3. Required Context for All Reordering Metrics ................6
2. Conventions Used in this Document ...............................7
3. A Reordered Packet Singleton Metric .............................7
3.1. Metric Name ................................................8
3.2. Metric Parameters ..........................................8
3.3. Definition .................................................8
3.4. Sequence Discontinuity Definition ..........................9
3.5. Evaluation of Reordering in Dimensions of Time or Bytes ...10
3.6. Discussion ................................................10
4. Sample Metrics .................................................11
4.1. Reordered Packet Ratio ....................................11
4.1.1. Metric Name ........................................11
4.1.2. Metric Parameters ..................................11
4.1.3. Definition .........................................12
4.1.4. Discussion .........................................12
4.2. Reordering Extent .........................................12
4.2.1. Metric Name ........................................12
4.2.2. Notation and Metric Parameters .....................12
4.2.3. Definition .........................................13
4.2.4. Discussion .........................................13
4.3. Reordering Late Time Offset ...............................14
4.3.1. Metric Name ........................................14
4.3.2. Metric Parameters ..................................14
4.3.3. Definition .........................................15
4.3.4. Discussion .........................................15
4.4. Reordering Byte Offset ....................................16
4.4.1. Metric Name ........................................16
4.4.2. Metric Parameters ..................................16
4.4.3. Definition .........................................16
4.4.4. Discussion .........................................17
4.5. Gaps between Multiple Reordering Discontinuities ..........17
4.5.1. Metric Names .......................................17
4.5.2. Parameters .........................................17
4.5.3. Definition of Reordering Discontinuity .............17
4.5.4. Definition of Reordering Gap .......................18
4.5.5. Discussion .........................................18
4.6. Reordering-Free Runs ......................................19
4.6.1. Metric Names .......................................19
4.6.2. Parameters .........................................19
4.6.3. Definition .........................................19
4.6.4. Discussion and Illustration ........................20
5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric ..21
5.1. Metric Name ...............................................21
5.2. Parameter Notation ........................................21
5.3. Definitions ...............................................22
5.4. Discussion ................................................22
6. Measurement and Implementation Issues ..........................23
6.1. Passive Measurement Considerations ........................26
7. Examples of Arrival Order Evaluation ...........................26
7.1. Example with a Single Packet Reordered ....................26
7.2. Example with Two Packets Reordered ........................28
7.3. Example with Three Packets Reordered ......................30
7.4. Example with Multiple Packet Reordering Discontinuities ...31
8. Security Considerations ........................................32
8.1. Denial-of-Service Attacks .................................32
8.2. User Data Confidentiality .................................32
8.3. Interference with the Metric ..............................32
9. IANA Considerations ............................................33
10. Normative References ..........................................35
11. Informative References ........................................36
12. Acknowledgements ..............................................37
Appendix A. Example Implementations in C (Informative) ............38
Appendix B. Fragment Order Evaluation (Informative) ...............41
B.1. Metric Name ...............................................41
B.2. Additional Metric Parameters ..............................41
B.3. Definition ................................................42
B.4. Discussion: Notes on Sample Metrics When Evaluating
Fragments .................................................43
Appendix C. Disclaimer and License ................................43
5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric ..21
5.1. Metric Name ...............................................21
5.2. Parameter Notation ........................................21
5.3. Definitions ...............................................22
5.4. Discussion ................................................22
6. Measurement and Implementation Issues ..........................23
6.1. Passive Measurement Considerations ........................26
7. Examples of Arrival Order Evaluation ...........................26
7.1. Example with a Single Packet Reordered ....................26
7.2. Example with Two Packets Reordered ........................28
7.3. Example with Three Packets Reordered ......................30
7.4. Example with Multiple Packet Reordering Discontinuities ...31
8. Security Considerations ........................................32
8.1. Denial-of-Service Attacks .................................32
8.2. User Data Confidentiality .................................32
8.3. Interference with the Metric ..............................32
9. IANA Considerations ............................................33
10. Normative References ..........................................35
11. Informative References ........................................36
12. Acknowledgements ..............................................37
Appendix A. Example Implementations in C (Informative) ............38
Appendix B. Fragment Order Evaluation (Informative) ...............41
B.1. Metric Name ...............................................41
B.2. Additional Metric Parameters ..............................41
B.3. Definition ................................................42
B.4. Discussion: Notes on Sample Metrics When Evaluating
Fragments .................................................43
Appendix C. Disclaimer and License ................................43
Ordered arrival is a property found in packets that transit their path, where the packet sequence number increases with each new arrival and there are no backward steps. The Internet Protocol [RFC791] [RFC2460] has no mechanisms to ensure either packet delivery or sequencing, and higher-layer protocols (above IP) should be prepared to deal with both loss and reordering. This memo defines reordering metrics.
有序到达是在传输其路径的数据包中发现的一种属性，其中数据包序列号随着每次新到达而增加，并且没有后退步骤。互联网协议[RFC791][RFC2460]没有确保数据包交付或排序的机制，更高层协议（IP以上）应准备好处理丢失和重新排序。此备忘录定义了重新排序指标。
A unique sequence identifier carried in each packet, such as an incrementing consecutive integer message number, establishes the source sequence.
在每个连续的消息序列中，如数据包递增序列，建立一个唯一的整数标识符。
The detection of reordering at the destination is based on packet arrival order in comparison with a non-reversing reference value [Cia03].
目的地处的重排序检测基于与非反转参考值相比的数据包到达顺序[Cia03]。
This metric is consistent with [RFC2330] and classifies arriving packets with sequence numbers smaller than their predecessors as out-of-order or reordered. For example, if sequentially numbered packets arrive 1,2,4,5,3, then packet 3 is reordered. This is equivalent to Paxon's reordering definition in [Pax98], where "late" packets were declared reordered. The alternative is to emphasize "premature" packets instead (4 and 5 in the example), but only the arrival of packet 3 distinguishes this circumstance from packet loss. Focusing attention on late packets allows us to maintain orthogonality with the packet loss metric. The metric's construction is very similar to the sequence space validation for received segments in [RFC793]. Earlier work to define ordered delivery includes [Cia00], [Ben99], [Lou01], [Bel02], [Jai02], and [Cia03].
该度量与[RFC2330]一致，并将序列号小于前一个序列号的到达数据包分类为无序或重新排序。例如，如果按顺序编号的数据包到达1,2,4,5,3，则数据包3被重新排序。在Paxon的定义中，REORDER数据包被声明为“REORDER”。替代方案是强调“过早”分组（在示例中为4和5），但只有分组3的到达将这种情况与分组丢失区分开来。将注意力集中在延迟数据包上使我们能够保持数据包丢失度量的正交性。度量的构造与[RFC793]中接收段的序列空间验证非常相似。早期定义订单交付的工作包括[Cia00]、[Ben99]、[Lou01]、[Bel02]、[Jai02]和[Cia03]。
A reordering metric is relevant for most applications, especially when assessing network support for Real-Time media streams. The extent of reordering may be sufficient to cause a received packet to be discarded by functions above the IP layer.
重新排序度量与大多数应用程序相关，尤其是在评估实时媒体流的网络支持时。重新排序的程度可能足以导致IP层以上的功能丢弃接收的分组。
Packet order may change during transfer, and several specific path characteristics can make reordering more likely.
在传输过程中，数据包顺序可能会发生变化，并且几个特定的路径特征可能使重新排序变得更可能。
Examples are:
例如：
* When two (or more) paths with slightly differing transfer times support a single packet stream or flow, packets traversing the longer path(s) may arrive out-of-order. Multiple paths may be used to achieve load balancing or may arise from route instability.
* 当传输时间稍有不同的两条（或多条）路径支持单个分组流或流时，穿过较长路径的分组可能会无序到达。多条路径可用于实现负载平衡，也可能因路由不稳定而产生。
* To increase capacity, a network device designed with multiple processors serving a single port (or parallel links) may reorder as a byproduct.
* 为了增加容量，设计有多个处理器为单个端口（或并行链路）服务的网络设备可以作为副产品重新排序。
* A layer-2 retransmission protocol that compensates for an error-prone link may cause packet reordering.
* 补偿易出错链路的第2层重传协议可能导致数据包重新排序。
* If for any reason the packets in a buffer are not serviced in the order of their arrival, their order will change.
* 如果出于任何原因，缓冲区中的数据包没有按照它们到达的顺序提供服务，那么它们的顺序将改变。
* If packets in a flow are assigned to multiple buffers (following evaluation of traffic characteristics, for example), and the buffers have different occupation levels and/or service rates, then order will likely change.
* 如果流中的数据包被分配给多个缓冲区（例如，在对流量特性进行评估之后），并且缓冲区具有不同的占用级别和/或服务速率，则顺序可能会改变。
When one or more of the above path characteristics are present continuously, reordering may be present on a steady-state basis. The steady-state reordering condition typically causes an appreciable fraction of packets to be reordered. This form of reordering is most easily detected by minimizing the spacing between test packets. Transient reordering may occur in response to network instability; temporary routing loops can cause periods of extreme reordering. This condition is characterized by long, in-order streams with occasional instances of reordering, sometimes with extreme correlation. However, we do not expect packet delivery in a completely random order, where, for example, the last packet or the first packet in a sample is equally likely to arrive first at the destination. Thus, we expect at least a minimal degree of order in the packet arrivals, as exhibited in real networks.
当一个或多个以上路径特征连续存在时，可在稳态基础上出现重新排序。稳态重新排序条件通常会导致相当一部分数据包被重新排序。这种形式的重新排序最容易通过最小化测试数据包之间的间隔来检测。网络不稳定时，可能会出现短暂的重新排序；临时路由循环可能会导致极端的重新排序。这种情况的特点是长的有序流，偶尔出现重新排序的情况，有时具有极端相关性。然而，我们并不期望分组以完全随机的顺序交付，例如，样本中的最后一个分组或第一个分组同样可能首先到达目的地。因此，我们期望分组到达中至少有最小程度的顺序，如在实际网络中所示。
The ability to restore order at the destination will likely have finite limits. Practical hosts have receiver buffers with finite size in terms of packets, bytes, or time (such as de-jitter buffers). Once the initial determination of reordering is made, it is useful to quantify the extent of reordering, or lateness, in all meaningful dimensions.
在目的地恢复订单的能力可能有有限的限制。实际主机的接收器缓冲区在数据包、字节或时间方面是有限的（例如去抖动缓冲区）。一旦重新排序的初始确定完成，在所有有意义的维度上量化重新排序的程度或延迟是很有用的。
The definitions below intend to satisfy the goals of:
以下定义旨在满足以下目标：
1. Determining whether or not packet reordering has occurred.
1. 确定是否已发生数据包重新排序。
2. Quantifying the degree of reordering. (We define a number of metrics to meet this goal, because receiving procedures differ by protocol or application. Since the effects of packet reordering vary with these procedures, a metric that quantifies a key aspect of one receiver's behavior could be irrelevant to
2. 量化重新排序的程度。（我们定义了许多指标来实现这一目标，因为接收过程因协议或应用程序而异。由于数据包重新排序的效果因这些过程而异，因此量化一个接收器行为的关键方面的指标可能与此无关
a different receiver. If all the metrics defined below are reported, they give a wide-ranging view of reordering conditions.)
一个不同的接收器。如果报告了下面定义的所有指标，则这些指标将提供重新排序条件的广泛视图。）
Reordering Metrics MUST:
重新排序指标必须：
+ have one or more applications, such as receiver design or network characterization, and a compelling relevance in the view of the interested community.
+ 具有一个或多个应用程序，例如接收器设计或网络特性，并且在感兴趣的社区中具有引人注目的相关性。
+ be computable "on the fly".
+ “在飞行中”是可计算的。
+ work even if the stream has duplicate or lost packets.
+ 即使流有重复或丢失的数据包，也可以工作。
It is desirable for Reordering Metrics to have one or more of the following attributes:
重新排序指标最好具有以下一个或多个属性：
+ ability to concatenate results for segments measured separately to estimate the reordering of an entire path
+ 能够连接单独测量的段的结果，以估计整个路径的重新排序
+ simplicity for easy consumption and understanding
+ 简单易用，易于理解
+ relevance to TCP design
+ 与TCP设计的相关性
+ relevance to real-time application performance
+ 与实时应用程序性能的相关性
The current set of metrics meets all the requirements above and provides all but the concatenation attribute (except in the case where measurements of path segments exhibit no reordering, and one may estimate that the complete path composed of these segments would also exhibit no reordering). However, satisfying these goals restricts the set of metrics to those that provide some clear insight into network characterization or receiver design. They are not likely to be exhaustive in their coverage of reordering effects on applications, and additional measurements may be possible.
当前度量集满足上述所有要求，并提供除连接属性以外的所有属性（路径段的测量显示无重新排序的情况除外，并且可以估计由这些段组成的完整路径也将显示无重新排序）。然而，满足这些目标将度量集限制在那些能够对网络特性或接收器设计提供一些清晰见解的度量集。它们不可能详尽地涵盖应用程序的重新排序影响，并且可能会进行额外的测量。
A critical aspect of all reordering metrics is their inseparable bond with the measurement conditions. Packet reordering is not well defined unless the full measurement context is reported. Therefore, all reordering metric definitions include the following parameters:
所有重新排序度量的一个关键方面是它们与度量条件之间不可分割的联系。除非报告完整的度量上下文，否则无法很好地定义数据包重新排序。因此，所有重新排序度量定义都包括以下参数：
1. The "Packet of Type-P" [RFC2330] identifiers for the packet stream, including the transport addresses for source and destination, and any other information that may result in different packet treatments.
1. 分组流的“P型分组”[RFC2330]标识符，包括源和目的地的传输地址，以及可能导致不同分组处理的任何其他信息。
2. The stream parameter set for the sending discipline, such as the parameters unique to periodic streams (as in [RFC3432]), TCP-like streams (as in [RFC3148]), or Poisson streams (as in [RFC2330]). The stream parameters include the packet size, specified either as a fixed value or as a pattern of sizes (as applicable).
2. 为发送规程设置的流参数，例如周期性流（如[RFC3432]）、类TCP流（如[RFC3148]）或泊松流（如[RFC2330]）所特有的参数。流参数包括数据包大小，指定为固定值或大小模式（如适用）。
Whenever a metric is reported, it MUST include a description of these parameters to provide a context for the results.
无论何时报告指标，都必须包括这些参数的描述，以提供结果的上下文。
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 [RFC2119]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different implementations are comparable, and to note instances when an implementation could perturb the network.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。尽管RFC 2119在编写时考虑了协议，但出于类似的原因，本文档中使用了关键词。它们用于确保两个不同实现的测量结果具有可比性，并用于记录实现可能干扰网络的实例。
In this memo, the characters "<=" should be read as "less than or equal to" and ">=" as "greater than or equal to".
在此备忘录中，字符“<=”应理解为“小于或等于”，而“>=”应理解为“大于或等于”。
The IPPM framework [RFC2330] describes the notions of singletons, samples, and statistics. For easy reference:
IPPM框架[RFC2330]描述了单例、样本和统计的概念。为方便参考：
By a 'singleton' metric, we refer to metrics that are, in a sense, atomic. For example, a single instance of "bulk throughput capacity" from one host to another might be defined as a singleton metric, even though the instance involves measuring the timing of a number of Internet packets.
通过“单例”度量，我们指的是某种意义上的原子度量。例如，从一个主机到另一个主机的“批量吞吐量容量”的单个实例可以定义为单例度量，即使该实例涉及测量多个因特网数据包的定时。
The evaluation of packet order requires several supporting concepts. The first is an algorithm (function) that produces a series of strictly monotonically increasing identifiers applied to packets at the source to uniquely establish the order of packet transmission (where a function, g(x), is strictly monotonically increasing if for any x>y, g(x)>g(y) ). The unique sequence identifier may simply be an incrementing consecutive integer message number, or a sequence number as used below. The prospect of sequence number rollover is discussed in Section 6.
包顺序的评估需要几个支持概念。第一种是算法（函数），该算法产生一系列严格单调递增的标识符，这些标识符应用于源处的分组，以唯一地建立分组传输的顺序（其中函数g（x），如果对于任何x>y，g（x）>g（y），则严格单调递增）。唯一序列标识符可以简单地是递增的连续整数消息编号，或者如下所述的序列编号。第6节讨论了序列号滚动的前景。
The second supporting concept is a stored value that is the "next expected" packet number. Under normal conditions, the value of Next Expected (NextExp) is the sequence number of the previous packet plus 1 for message numbering. (In general, the receiver reproduces the
第二个支持概念是存储值，它是“下一个预期的”数据包编号。在正常情况下，下一个预期值（NextExp）是前一个数据包的序列号加上消息编号的1。（通常，接收方复制
sender's algorithm and the sequence of identifiers so that the "next expected" can be determined.)
发送方的算法和标识符序列，以便可以确定“下一个期望值”。）
Each packet within a packet stream can be evaluated with this order singleton metric.
数据包流中的每个数据包都可以使用这个顺序单例度量进行评估。
Type-P-Reordered
类型-P-重新排序
+ Src, the IP address of a host.
+ Src，主机的IP地址。
+ Dst, the IP address of a host.
+ Dst，主机的IP地址。
+ SrcTime, the time of packet emission from the source (or wire time).
+ SrcTime，从源发送数据包的时间（或连线时间）。
+ s, the unique packet sequence number applied at the source, in units of messages.
+ s、 应用于源的唯一数据包序列号，以消息为单位。
+ NextExp, the next expected sequence number at the destination, in units of messages. The stored value in NextExp is determined from a previously arriving packet.
+ NextExp，目的地的下一个预期序列号，以消息为单位。NextExp中的存储值由先前到达的数据包确定。
And optionally:
或者：
+ PayloadSize, the number of bytes contained in the information field and referred to when the SrcByte sequence is based on bytes transferred.
+ PayloadSize，信息字段中包含的字节数，当SrcByte序列基于传输的字节数时引用。
+ SrcByte, the packet sequence number applied at the source, in units of payload bytes.
+ SrcByte，应用于源的数据包序列号，以有效负载字节为单位。
If a packet s (sent at time, SrcTime) is found to be reordered by comparison with the NextExp value, its Type-P-Reordered = TRUE; otherwise, Type-P-Reordered = FALSE, as defined below:
如果REORDER的类型是REORDER，则在NEXD时将其与REORDER的类型进行比较（如果REORDER的类型是REORDER，则为REORDER）；否则，Type-P-Reordered=FALSE，定义如下：
The value of Type-P-Reordered is defined as TRUE if s < NextExp (the packet is reordered). In this case, the NextExp value does not change.
如果s<nextextsp（数据包被重新排序），则Type-P-Reordered的值定义为TRUE。在这种情况下，NextExp值不会更改。
The value of Type-P-Reordered is defined as FALSE if s >= NextExp (the packet is in-order). In this case, NextExp is set to s+1 for comparison with the next packet to arrive.
如果s>=NextExp（数据包按顺序排列），则Type-P-Reordered的值定义为FALSE。在这种情况下，NextExp设置为s+1，以便与下一个要到达的数据包进行比较。
Since the NextExp value cannot decrease, it provides a non-reversing order criterion to identify reordered packets.
由于NextExp值不能减小，因此它提供了一个非反转顺序标准来识别重新排序的数据包。
This definition can also be specified in pseudo-code.
此定义也可以在伪代码中指定。
On successful arrival of a packet with sequence number s:
序列号为s的数据包成功到达时：
if s >= NextExp then /* s is in-order */
NextExp = s + 1;
Type-P-Reordered = False;
else /* when s < NextExp */
Type-P-Reordered = True
if s >= NextExp then /* s is in-order */
NextExp = s + 1;
Type-P-Reordered = False;
else /* when s < NextExp */
Type-P-Reordered = True
Packets with s > NextExp are a special case of in-order delivery. This condition indicates a sequence discontinuity, because of either packet loss or reordering. Reordered packets must arrive for the sequence discontinuity to be defined as a reordering discontinuity (see Section 4).
s>NextExp的数据包是顺序传递的特殊情况。这种情况表示由于数据包丢失或重新排序而导致序列不连续。重新排序的数据包必须到达才能将序列不连续定义为重新排序不连续（见第4节）。
We define two different states for in-order packets.
我们为顺序数据包定义了两种不同的状态。
When s = NextExp, the original sequence has been maintained, and there is no discontinuity present.
当s=NextExp时，原始序列保持不变，不存在间断。
When s > NextExp, some packets in the original sequence have not yet arrived, and there is a sequence discontinuity associated with packet s. The size of the discontinuity is s - NextExp, equal to the number of packets presently missing, either reordered or lost.
当s>NextExp时，原始序列中的一些数据包尚未到达，并且存在与数据包s相关联的序列不连续性。不连续的大小是s-NextExp，等于当前丢失、重新排序或丢失的数据包数。
In pseudo-code:
在伪代码中：
On successful arrival of a packet with sequence number s:
序列号为s的数据包成功到达时：
if s >= NextExp, then /* s is in-order */
if s > NextExp then
SequenceDiscontinuty = True;
SeqDiscontinutySize = s - NextExp;
else
SequenceDiscontinuty = False;
NextExp = s + 1;
Type-P-Reordered = False;
if s >= NextExp, then /* s is in-order */
if s > NextExp then
SequenceDiscontinuty = True;
SeqDiscontinutySize = s - NextExp;
else
SequenceDiscontinuty = False;
NextExp = s + 1;
Type-P-Reordered = False;
else /* when s < NextExp */
Type-P-Reordered = True;
SequenceDiscontinuty = False;
else /* when s < NextExp */
Type-P-Reordered = True;
SequenceDiscontinuty = False;
Whether any sequence discontinuities occur (and their size) is determined by the conditions causing loss and/or reordering along the measurement path. Note that a packet could be reordered at one point and subsequently lost elsewhere on the path, but this cannot be known from observations at the destination.
是否出现任何序列不连续（及其大小）取决于沿测量路径造成损失和/或重新排序的条件。请注意，数据包可能会在某一点重新排序，然后在路径上的其他位置丢失，但这无法从目的地的观察中得知。
It is possible to use alternate dimensions of time or payload bytes to test for reordering in the definition of Section 3.3, as long as the SrcTimes and SrcBytes are unique and reliable. Sequence Discontinuities are easily defined and detected with message numbering; however, this is not so simple in the dimensions of time or bytes. This is a detractor for the alternate dimensions because the sequence discontinuity definition plays a key role in the sample metrics that follow.
在第3.3节的定义中，只要SrcTimes和SrcBytes是唯一和可靠的，就可以使用时间或有效负载字节的替代维度来测试重新排序。序列不连续性很容易通过消息编号来定义和检测；然而，这在时间或字节的维度上并不是那么简单。这是备选维度的一个贬损因素，因为序列不连续性定义在随后的样本度量中起着关键作用。
It is possible to detect sequence discontinuities with payload byte numbering, but only when the test device knows exactly what value to assign as NextExp in response to any packet arrival. This is possible when the complete pattern of payload sizes is stored at the destination, or if the size pattern can be generated using a pseudo-random number generator and a shared seed. If payload size is constant, byte numbering adds needless complexity over message numbering.
通过有效负载字节编号可以检测序列的不连续性，但只有当测试设备确切地知道响应任何数据包到达而分配为NextExp的值时，才可以检测序列的不连续性。当有效负载大小的完整模式存储在目的地时，或者如果可以使用伪随机数生成器和共享种子生成大小模式，则这是可能的。若有效负载大小为常量，字节编号会比消息编号增加不必要的复杂性。
It may be possible to detect sequence discontinuities with periodic streams and source time numbering, but there are practical pitfalls with sending exactly on-schedule and with clock reliability.
可以通过周期性流和源时间编号来检测序列不连续性，但精确按计划发送和时钟可靠性存在实际缺陷。
The dimensions of time and bytes remain an important basis for characterizing the extent of reordering, as described in Sections 4.3 and 4.4.
如第4.3节和第4.4节所述，时间和字节的维度仍然是表征重新排序程度的重要基础。
Any arriving packet bearing a sequence number from the sequence that establishes the NextExp value can be evaluated to determine whether it is in-order or reordered, based on a previous packet's arrival. In the case where NextExp is Undefined (because the arriving packet is the first successful transfer), the packet is designated in-order (Type-P-Reordered=FALSE).
根据前一个数据包的到达，可以评估任何带有建立NextExp值的序列号的到达数据包，以确定它是有序的还是重新排序的。在NextExp未定义的情况下（因为到达的数据包是第一次成功传输），数据包按顺序指定（Type-P-Reordered=FALSE）。
This metric assumes reassembly of packet fragments before evaluation. In principle, it is possible to use the Type-P-Reordered metric to evaluate reordering among packet fragments, but each fragment must contain source sequence information. See Appendix B, "Fragment Order Evaluation", for more detail.
此度量假定在评估之前重新组装数据包片段。原则上，可以使用Type-P-Reordered度量来评估数据包片段之间的重新排序，但每个片段必须包含源序列信息。有关更多详细信息，请参见附录B“碎片顺序评估”。
If duplicate packets (multiple non-corrupt copies) arrive at the destination, they MUST be noted, and only the first to arrive is considered for further analysis (copies would be declared reordered according to the definition above). This requirement has the same storage implications as earlier IPPM metrics and follows the precedent of [RFC2679]. We provide a suggestion to minimize storage size needed in Section 6 on Measurement and Implementation Issues.
如果重复数据包（多个未损坏的副本）到达目的地，则必须注意它们，并且只考虑第一个到达的数据包进行进一步分析（副本将根据上述定义声明重新排序）。此要求与早期IPPM指标具有相同的存储含义，并遵循[RFC2679]的先例。在关于度量和实现问题的第6节中，我们提供了一个最小化存储大小的建议。
In this section, we define metrics applicable to a sample of packets from a single source sequence number system. When reordering occurs, it is highly desirable to assert the degree to which a packet is out-of-order or reordered with respect other packets. This section defines several metrics that quantify the extent of reordering in various units of measure. Each metric highlights a relevant use.
在本节中，我们定义了适用于来自单一源序列号系统的数据包样本的度量。当发生重新排序时，非常希望断言数据包的无序程度或相对于其他数据包的重新排序程度。本节定义了若干度量标准，用于量化各种度量单位中的重新排序程度。每个指标都突出了相关用途。
The metrics in the sub-sections below have a network characterization orientation, but also have relevance to receiver design where reordering compensation is of interest. We begin with a simple ratio metric indicating the reordered portion of the sample.
以下小节中的指标具有网络特征化的方向，但也与接收器设计相关，其中重新排序补偿很重要。我们从一个简单的比率指标开始，该指标指示样本的重新排序部分。
Type-P-Reordered-Ratio-Stream
类型-P-重新排序-比率-流
The parameter set includes Type-P-Reordered singleton parameters; the parameters unique to Poisson streams (as in [RFC2330]), periodic streams (as in [RFC3432]), or TCP-like streams (as in [RFC3148]); packet size or size patterns; and the following:
参数集包括类型P-重排序单态参数；泊松流（如[RFC2330]中）、周期流（如[RFC3432]中）或TCP类流（如[RFC3148]中）特有的参数；数据包大小或大小模式；以及以下各项：
+ T0, a start time
+ T0，开始时间
+ Tf, an end time
+ Tf，结束时间
+ dT, a waiting time for each packet to arrive, in seconds
+ dT，每个数据包到达的等待时间，以秒为单位
+ K, the total number of packets in the stream sent from source to destination
+ K、 流中从源发送到目标的数据包总数
+ L, the total number of packets received (arriving between T0 and Tf+dT) out of the K packets sent. Recall that identical copies (duplicates) have been removed, so L <= K.
+ 五十、 发送的K个数据包中接收到的数据包总数（在T0和Tf+dT之间到达）。回想一下，相同的副本（副本）已被删除，因此L<=K。
+ R, the ratio of reordered packets to received packets, defined below
+ R、 重新排序的数据包与接收到的数据包的比率，定义如下
Note that parameter dT is effectively the threshold for declaring a packet as lost. The IPPM Packet Loss Metric [RFC2680] declines to recommend a value for this threshold, saying instead that "good engineering, including an understanding of packet lifetimes, will be needed in practice."
注意，参数dT实际上是声明数据包丢失的阈值。IPPM数据包丢失指标[RFC2680]拒绝推荐该阈值的值，而是表示“在实践中需要良好的工程设计，包括对数据包寿命的理解。”
Given a stream of packets sent from a source to a destination, the ratio of reordered packets in the sample is
给定从源发送到目的地的数据包流，样本中重新排序的数据包的比率为
R = (Count of packets with Type-P-Reordered=TRUE) / ( L )
R = (Count of packets with Type-P-Reordered=TRUE) / ( L )
This fraction may be expressed as a percentage (multiply by 100). Note that in the case of duplicate packets, only the first copy is used.
该分数可表示为百分比（乘以100）。请注意，在重复数据包的情况下，仅使用第一个副本。
When the Type-P-Reordered-Ratio-Stream is zero, no further reordering metrics need be examined for that sample. Therefore, the value of this metric is its simple ability to summarize the results for a reordering-free sample.
当Type-P-Reordered-Ratio-Stream为零时，不需要为该样本检查进一步的重新排序度量。因此，该指标的价值在于其总结无需重新排序的样本结果的简单能力。
This section defines the extent to which packets are reordered and associates a specific sequence discontinuity with each reordered packet. This section inherits the Parameters defined above.
本节定义了数据包重新排序的范围，并将特定的序列不连续性与每个重新排序的数据包相关联。本节继承上面定义的参数。
Type-P-Packet-Reordering-Extent-Stream
Type-P-Packet-Reordering-Extent-Stream
Recall that K is the number of packets in the stream at the source, and L is the number of packets received at the destination.
回想一下，K是源处流中的数据包数，L是目标处接收的数据包数。
Each packet has been assigned a sequence number, s, a consecutive integer from 1 to K in the order of packet transmission (at the source).
每个数据包都被分配了一个序列号s，一个从1到K的连续整数，按照数据包传输的顺序（在源位置）。
Let s[1], s[2], ..., s[L] represent the original sequence numbers associated with the packets in order of arrival.
设s[1]，s[2]，…，s[L]表示与分组按到达顺序关联的原始序列号。
s[i] can be thought of as a vector, where the index i is the arrival position of the packet with sequence number s. In theory, any source sequence number could appear in any arrival position, but this is unlikely in reality.
s[i]可以被认为是向量，其中索引i是序列号为s的分组的到达位置。理论上，任何源序列号都可能出现在任何到达位置，但这在现实中是不可能的。
Consider a reordered packet (Type-P-Reordered=TRUE) with arrival index i and source sequence number s[i]. There exists a set of indexes j (1 <= j < i) such that s[j] > s[i].
考虑具有到达索引I和源序列号s[i]的重新排序分组（类型-p重排序＝真）。存在一组索引j（1<=j<i），使得s[j]>s[i]。
The new parameters are:
新参数包括：
+ i, the index for arrival position, where i-1 represents an arrival earlier than i.
+ i、 到达位置的索引，其中i-1表示早于i的到达。
+ j, a set of one or more arrival indexes, where 1 <= j < i.
+ j、 一组一个或多个到达索引，其中1<=j<i。
+ s[i], the original sequence numbers, s, in order of arrival.
+ s[i]，原始序列号s，按到达顺序排列。
+ e, the Reordering Extent, in units of packets, defined below.
+ e、 以下定义的以数据包为单位的重新排序范围。
The reordering extent, e, of packet s[i] is defined to be i-j for the smallest value of j where s[j] > s[i].
分组s[i]的重新排序范围e被定义为j的最小值的i-j，其中s[j]>s[i]。
Informally, the reordering extent is the maximum distance, in packets, from a reordered packet to the earliest packet received that has a larger sequence number. If a packet is in-order, its reordering extent is undefined. The first packet to arrive is in-order by definition and has undefined reordering extent.
非正式地说，重新排序范围是从重新排序的数据包到具有较大序列号的最早接收的数据包的最大距离（以数据包为单位）。如果数据包有序，则其重新排序范围未定义。第一个到达的数据包按照定义是有序的，并且具有未定义的重新排序范围。
Comment on the definition of extent: For some arrival orders, the assignment of a simple position/distance as the reordering extent tends to overestimate the receiver storage needed to restore order. A more accurate and complex procedure to calculate packet storage would be to subtract any earlier reordered packets that the receiver could pass on to the upper layers (see the Byte Offset metric). With the bias understood, this definition is deemed sufficient, especially for those who demand "on the fly" calculations.
对范围定义的评论：对于某些到货订单，将简单位置/距离分配为重新排序范围往往会高估恢复订单所需的接收方存储。计算数据包存储的一个更准确、更复杂的过程是减去接收方可以传递到上层的任何先前重新排序的数据包（参见字节偏移量度量）。理解了偏差后，这一定义就足够了，特别是对于那些要求“即时”计算的人。
The packet with index j (s[j], identified in the Definition above) is the reordering discontinuity associated with packet s at index i (s[i]). This definition is formalized below.
具有索引j（s[j]，在上述定义中标识）的分组是与索引i（s[i]）处的分组s相关联的重新排序不连续性。这一定义在下文正式说明。
Note that the K packets in the stream could be some subset of a larger stream, but L is still the total number of packets received out of the K packets sent in that subset.
注意，流中的K个分组可以是较大流的某个子集，但是L仍然是在该子集中发送的K个分组中接收到的分组的总数。
If a receiver intends to restore order, then its buffer capacity determines its ability to handle packets that are reordered. For cases with single reordered packets, the extent e gives the number of packets that must be held in the receiver's buffer while waiting for the reordered packet to complete the sequence. For more complex scenarios, the extent may be an overestimate of required storage (see Section 4.4 on Reordering Byte Offset and the examples in Section 7). Also, if the receiver purges its buffer for any reason, the extent metric would not reflect this behavior, assuming instead that the receiver would exhaustively attempt to restore order.
若接收器打算恢复顺序，则其缓冲区容量决定其处理重新排序的数据包的能力。对于具有单个重新排序的数据包的情况，区段e给出在等待重新排序的数据包完成序列时必须保存在接收器缓冲器中的数据包的数量。对于更复杂的场景，范围可能是对所需存储的高估（请参阅第4.4节“重新排序字节偏移量”和第7节中的示例）。此外，如果接收方出于任何原因清除其缓冲区，那么扩展度量将不会反映此行为，而是假设接收方将彻底尝试恢复顺序。
Although reordering extent primarily quantifies the offset in terms of arrival position, it may also be useful for determining the portion of reordered packets that can or cannot be restored to order in a typical receiver buffer based on their arrival order alone (and without the aid of retransmission).
尽管重新排序范围主要根据到达位置量化偏移量，但它也可用于确定重新排序的分组的部分，这些分组可以或不能在典型的接收机缓冲器中仅基于它们的到达顺序恢复到顺序（并且不需要重传的帮助）。
A sample's reordering extents may be expressed as a histogram to easily summarize the frequency of various extents.
样本的重新排序范围可以表示为直方图，以方便地总结各种范围的频率。
Reordered packets can be assigned offset values indicating their lateness in terms of buffer time that a receiver must possess to accommodate them. Offset metrics are calculated only on reordered packets, as identified by the reordered packet singleton metric in Section 3.
可以为重新排序的数据包分配偏移量值，以指示其延迟，即接收方必须拥有的缓冲时间来容纳它们。偏移量度量仅在重新排序的数据包上计算，如第3节中重新排序的数据包单例度量所示。
Type-P-Packet-Late-Time-Stream
P型分组延迟时间流
In addition to the parameters defined for Type-P-Reordered-Ratio-Stream, we specify:
除了为类型P-Reordered-Ratio-Stream定义的参数外，我们还指定：
+ DstTime, the time that each packet in the stream arrives at the destination, and may be associated with index i, or packet s[i]
+ dstime，流中的每个分组到达目的地的时间，并且可以与索引i或分组s[i]相关联
+ LateTime(s[i]), the offset of packet s[i] in units of seconds, defined below
+ LateTime（s[i]），数据包s[i]的偏移量，以秒为单位，定义如下
Lateness in time is calculated using destination times. When received packet s[i] is reordered and has a reordering extent e, then:
使用目标时间计算时间延迟。当接收到的数据包s[i]被重新排序并且具有重新排序范围e时，则：
LateTime(s[i]) = DstTime(i)-DstTime(i-e)
LateTime(s[i]) = DstTime(i)-DstTime(i-e)
Alternatively, using similar notation to that of Section 4.2, an equivalent definition is:
或者，使用与第4.2节类似的符号，等效定义为：
LateTime(s[i]) = DstTime(i)-DstTime(j), for min{j|1<=j<i} that satisfies s[j]>s[i].
LateTime（s[i]）=DstTime（i）-DstTime（j），对于满足s[j]>s[i]的min{j|1<=j<i}。
The offset metrics can help predict whether reordered packets will be useful in a general receiver buffer system with finite limits. The limit may be the time of storage prior to a cyclic play-out instant (as with de-jitter buffers).
偏移量度量有助于预测重新排序的数据包在具有有限限制的一般接收器缓冲系统中是否有用。限制可能是循环播放瞬间之前的存储时间（与去抖动缓冲器一样）。
Note that the one-way IP Packet Delay Variation (IPDV) [RFC3393] gives the delay variation for a packet with respect to the preceding packet in the source sequence. Lateness and IPDV give an indication of whether a buffer at the destination has sufficient storage to accommodate the network's behavior and restore order. When an earlier packet in the source sequence is lost, IPDV will necessarily be undefined for adjacent packets, and LateTime may provide the only way to evaluate the usefulness of a packet.
注意，单向IP分组延迟变化（IPDV）[RFC3393]给出了分组相对于源序列中的前一分组的延迟变化。Lateness和IPDV指示目标缓冲区是否有足够的存储空间来适应网络行为和恢复顺序。当源序列中较早的分组丢失时，相邻分组的IPDV必然是未定义的，并且LateTime可能提供评估分组有用性的唯一方法。
In the case of de-jitter buffers, there are circumstances where the receiver employs loss concealment at the intended play-out time of a late packet. However, if this packet arrives out of order, the Late Time determines whether the packet is still useful. IPDV no longer applies, because the receiver establishes a new play-out schedule with additional buffer delay to accommodate similar events in the future (this requires very minimal processing).
在去抖动缓冲器的情况下，存在接收机在延迟分组的预期播放时间采用丢失隐藏的情况。但是，如果该数据包到达时出现故障，则延迟时间决定该数据包是否仍然有用。IPDV不再适用，因为接收器建立了一个新的播放时间表，带有额外的缓冲区延迟，以适应未来的类似事件（这需要非常小的处理）。
The combination of loss and reordering influences the LateTime metric. If presented with the arrival sequence 1, 10, 5 (where packets 2, 3, 4, and 6 through 9 are lost), LateTime would not indicate exactly how "late" packet 5 is from its intended arrival position. IPDV [RFC3393] would not capture this either, because of the lack of adjacent packet pairs. Assuming a periodic stream [RFC3432], an expected arrival time could be defined for all packets, but this is essentially a single-point delay variation metric (as defined in ITU-T Recommendations [I.356] and [Y.1540]), and not a reordering metric.
损失和重新排序的组合会影响延迟度量。如果呈现了到达序列1、10、5（其中分组2、3、4和6到9丢失），LateTime将不会准确地指示分组5距离其预期到达位置的“延迟”程度。IPDV[RFC3393]也不会捕捉到这一点，因为缺少相邻的数据包对。假设周期流[RFC3432]，可以为所有数据包定义预期到达时间，但这本质上是单点延迟变化度量（如ITU-T建议[I.356]和[Y.1540]中所定义），而不是重新排序度量。
A sample's LateTime results may be expressed as a histogram to summarize the frequency of buffer times needed to accommodate reordered packets and permit buffer tuning on that basis. A cumulative distribution function (CDF) with buffer time vs. percent of reordered packets accommodated may be informative.
样本的LateTime结果可以表示为直方图，以总结适应重新排序的数据包所需的缓冲时间频率，并允许在此基础上进行缓冲区调整。具有缓冲时间与容纳的重新排序的分组的百分比的累积分布函数（CDF）可以是信息性的。
Reordered packets can be assigned offset values indicating the storage in bytes that a receiver must possess to accommodate them. Offset metrics are calculated only on reordered packets, as identified by the reordered packet singleton metric in Section 3.
可以为重新排序的数据包分配偏移量值，以字节为单位指示接收器必须拥有的存储空间以容纳它们。偏移量度量仅在重新排序的数据包上计算，如第3节中重新排序的数据包单例度量所示。
Type-P-Packet-Byte-Offset-Stream
Type-P-Packet-Byte-Offset-Stream
We use the same parameters defined earlier, including the optional parameters of SrcByte and PayloadSize, and define:
我们使用前面定义的相同参数，包括可选参数SrcByte和PayloadSize，并定义：
+ ByteOffset(s[i]), the offset of packet s[i] in bytes
+ 字节偏移量（s[i]），数据包s[i]的偏移量，以字节为单位
The Byte stream offset for reordered packet s[i] is the sum of the payload sizes of packets qualified by the following criteria:
重新排序的数据包s[i]的字节流偏移量是符合以下标准的数据包的有效负载大小之和：
* The arrival is prior to the reordered packet, s[i], and
* 到达时间在重新排序的数据包s[i]之前，并且
* The send sequence number, s, is greater than s[i].
* 发送序列号i大于s。
Packets that meet both these criteria are normally buffered until the sequence beneath them is complete. Note that these criteria apply to both in-order and reordered packets.
满足这两个条件的数据包通常被缓冲，直到它们下面的序列完成。请注意，这些标准同时适用于按顺序和重新排序的数据包。
For reordered packet s[i] with a reordering extent e:
对于具有重排序范围e的重排序数据包s[i]：
ByteOffset(s[i]) = Sum[qualified packets]
= Sum[PayloadSize(packet at i-1 if qualified),
PayloadSize(packet at i-2 if qualified), ...
PayloadSize(packet at i-e always qualified)]
ByteOffset(s[i]) = Sum[qualified packets]
= Sum[PayloadSize(packet at i-1 if qualified),
PayloadSize(packet at i-2 if qualified), ...
PayloadSize(packet at i-e always qualified)]
Using our earlier notation:
使用我们前面的符号：
ByteOffset(s[i]) =
Sum[payloads of s[j] where s[j]>s[i] and i > j >= i-e]
ByteOffset(s[i]) =
Sum[payloads of s[j] where s[j]>s[i] and i > j >= i-e]
We note that estimates of buffer size due to reordering depend greatly on the test stream, in terms of the spacing between test packets and their size, especially when packet size is variable. In these and other circumstances, it may be most useful to characterize offset in terms of the payload size(s) of stored packets, using the Type-P-packet-Byte-Offset-Stream metric.
我们注意到，由于重新排序而产生的缓冲区大小的估计在很大程度上取决于测试流，即测试数据包之间的间隔及其大小，特别是当数据包大小可变时。在这些和其他情况下，使用Type-P-packet-Byte-offset-Stream度量，根据存储的分组的有效负载大小来表征偏移量可能是最有用的。
The byte offset metric can help predict whether reordered packets will be useful in a general receiver buffer system with finite limits. The limit is expressed as the number of bytes the buffer can store.
字节偏移量度量有助于预测重新排序的数据包在具有有限限制的一般接收器缓冲系统中是否有用。该限制表示为缓冲区可以存储的字节数。
A sample's ByteOffset results may be expressed as a histogram to summarize the frequency of buffer lengths needed to accommodate reordered packets and permit buffer tuning on that basis. A CDF with buffer size vs. percent of reordered packets accommodated may be informative.
样本的字节偏移量结果可以表示为直方图，以总结容纳重新排序的数据包所需的缓冲区长度频率，并允许在此基础上进行缓冲区调整。缓冲区大小与容纳的重新排序数据包的百分比的CDF可能是信息性的。
Type-P-Packet-Reordering-Gap-Stream Type-P-Packet-Reordering-GapTime-Stream
Type-P-Packet-Reordering-Gap-Stream Type-P-Packet-Reordering-GapTime-Stream
We use the same parameters defined earlier, but add the convention that index i' is greater than i, likewise j' > j, and define:
我们使用前面定义的相同参数，但添加了索引i'大于i的约定，同样是j'>j，并定义：
+ Gap(s[j']), the Reordering Gap of packet s[j'] in units of integer messages
+ Gap（s[j']），以整数消息为单位的数据包s[j']的重新排序间隙
and the OPTIONAL parameter:
和可选参数：
+ GapTime(s[j']), the Reordering Gap of packet s[j'] in units of seconds
+ GapTime（s[j']），数据包s[j']的重新排序间隔，以秒为单位
All reordered packets are associated with a packet at a reordering discontinuity, defined as the in-order packet s[j] that arrived at the minimum value of j (1<=j<i) for which s[j]> s[i].
所有重新排序的分组与处于重新排序不连续性的分组相关联，该分组被定义为到达s[j]>s[i的最小值j（1<=j<i）的顺序分组s[j]。
Note that s[j] will have been found to cause a sequence discontinuity, where s > NextExp when evaluated with the reordered singleton metric as described in Section 3.4.
注意，已发现s[j]会导致序列不连续性，其中s>nextex p在使用第3.4节中所述的重新排序单态度量进行评估时。
Recall that i - e = min(j). Subsequent reordered packets may be associated with the same s[j], or with a different discontinuity. This fact is used in the definition of the Reordering Gap, below.
回想一下，i-e=min（j）。随后重新排序的分组可以与相同的s[j]相关联，或者与不同的不连续性相关联。这一事实在下文重新排序间隙的定义中使用。
A reordering gap is the distance between successive reordering discontinuities. The Type-P-Packet-Reordering-Gap-Stream metric assigns a value for Gap(s[j']) to (all) packets in a stream (and a value for GapTime(s[j']), when reported).
重新排序间隙是连续重新排序不连续之间的距离。Type-P-Packet-Reordering-Gap-Stream度量将Gap（s[j']）的值分配给流中的（所有）数据包（以及GapTime（s[j']），当报告时）。
If:
如果：
the packet s[j'] is found to be a reordering discontinuity, based on the arrival of reordered packet s[i'] with extent e', and
发现分组s[j']是基于带区段e'的重新排序分组s[i']的到达的重新排序不连续性，并且
an earlier reordering discontinuity s[j], based on the arrival of reordered packet s[i] with extent e was already detected, and
基于带区段e的重新排序的分组s[i]的到达，已经检测到先前的重新排序不连续性s[j]，并且
i' > i, and
我,我,
there are no reordering discontinuities between j and j',
j和j'之间不存在重新排序的不连续性，
then the Reordering Gap for packet s[j'] is the difference between the arrival positions the reordering discontinuities, as shown below:
然后，数据包s[j']的重新排序间隔是到达位置与重新排序不连续性之间的差值，如下所示：
Gap(s[j']) = (j') - (j)
Gap(s[j']) = (j') - (j)
Gaps MAY also be expressed in time:
差距也可以用时间表示：
GapTime(s[j']) = DstTime(j') - DstTime(j)
GapTime(s[j']) = DstTime(j') - DstTime(j)
Otherwise:
否则：
Gap(s[j']) (and GapTime(s[j']) ) for packet s[j'] is 0.
数据包s[j']的间隙（s[j']）（和间隙时间（s[j']）为0。
When separate reordering discontinuities can be distinguished, a count may also be reported (along with the discontinuity description, such as the number of reordered packets associated with that discontinuity and their extents and offsets). The Gaps between a
当可以区分单独的重新排序不连续性时，还可以报告计数（连同不连续性描述，例如与该不连续性相关联的重新排序的分组的数量及其范围和偏移量）。一个国家之间的差距
sample's reordering discontinuities may be expressed as a histogram to easily summarize the frequency of various gaps. Reporting the mode, average, range, etc., may also summarize the distributions.
样本的重新排序不连续性可以表示为直方图，以便于总结各种间隙的频率。报告模式、平均值、范围等也可以总结分布情况。
The Gap metric may help to correlate the frequency of reordering discontinuities with their cause. Gap lengths are also informative to receiver designers, revealing the period of reordering discontinuities. The combination of reordering gaps and extent reveals whether receivers will be required to handle cases of overlapping reordered packets.
间隙度量可能有助于将重新排序不连续的频率与其原因关联起来。间隙长度也为接收器设计者提供了信息，揭示了重新排序不连续的周期。重新排序间隔和范围的组合揭示了接收机是否需要处理重叠重新排序数据包的情况。
This section defines a metric based on a count of consecutive in-order packets between reordered packets.
本节根据重新排序的数据包之间的连续顺序数据包计数定义度量。
Type-P-Packet-Reordering-Free-Run-x-numruns-Stream Type-P-Packet-Reordering-Free-Run-q-squruns-Stream Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream
Type-P-Packet-Reordering-Free-Run-x-numruns-Stream-P-Packet-Reordering-Free-Run-q-squrons-Stream-Type-P-Packet-Reordering-Free-Run-P-numpkts-Stream-P-Packet-Reordering-Free-Run-a-acpkts-Stream
We use the same parameters defined earlier and define the following:
我们使用前面定义的相同参数，并定义以下内容：
+ r, the run counter
+ r、 柜台
+ x, the number of runs, also the number of reordered packets
+ x、 运行数，以及重新排序的数据包数
+ a, the accumulator of in-order packets
+ a、 有序数据包的累加器
+ p, the number of packets (when the stream is complete, p=(x+a)=L)
+ p、 数据包数（流完成时，p=（x+a）=L）
+ q, the sum of the squares of the runs counted
+ q、 计算的行程平方和
As packets in a sample arrive at the destination, the count of in-order packets between reordered packets is a Reordering-Free run. Note that the minimum run-length is zero according to this definition. A pseudo-code example follows:
当样本中的数据包到达目的地时，重新排序的数据包之间的有序数据包计数是重新排序的自由运行。请注意，根据此定义，最小运行长度为零。下面是一个伪代码示例：
r = 0; /* r is the run counter */
x = 0; /* x is the number of runs */
a = 0; /* a is the accumulator of in-order packets */
p = 0; /* p is the number of packets */
r = 0; /* r is the run counter */
x = 0; /* x is the number of runs */
a = 0; /* a is the accumulator of in-order packets */
p = 0; /* p is the number of packets */
q = 0; /* q is the sum of the squares of the runs counted */
q = 0; /* q is the sum of the squares of the runs counted */
while(packets arrive with sequence number s)
{
p++;
if (s >= NextExp) /* s is in-order */
then r++;
a++;
else /* s is reordered */
q+= r*r;
r = 0;
x++;
}
while(packets arrive with sequence number s)
{
p++;
if (s >= NextExp) /* s is in-order */
then r++;
a++;
else /* s is reordered */
q+= r*r;
r = 0;
x++;
}
Each in-order arrival increments the run counter and the accumulator of in-order packets; each reordered packet resets the run counter after adding it to the sum of the squared lengths.
每个顺序到达增加顺序数据包的运行计数器和累加器；每个重新排序的数据包在将其添加到平方长度之和后重置运行计数器。
Each arrival of a reordered packet yields a new run count. Long runs accompany periods where order was maintained, while short runs indicate frequent or multi-packet reordering.
重新排序的数据包的每次到达都会产生一个新的运行计数。长时间运行伴随着维持订单的时间段，而短时间运行表示频繁或多数据包重新排序。
The percent of packets in-order is 100*a/p
按顺序排列的数据包百分比为100*a/p
The average Reordering-Free run length is a/x
平均重新排序自由行程长度为a/x
The q counter gives an indication of variation of the Reordering-Free runs from the average by comparing q/a to a/x ((q/a)/(a/x)).
q计数器通过比较q/a和a/x（（q/a）/（a/x））来指示重新排序自由行程相对于平均值的变化。
Type-P-packet-Reordering-Free-Run-Stream parameters give a brief summary of the stream's reordering characteristics including the average reordering-free run length, and the variation of run lengths; therefore, a key application of this metric is network evaluation.
Type-P-packet-Reordering-Free-Run-Stream参数简要总结了流的重新排序特性，包括平均重新排序自由运行长度和运行长度的变化；因此，该指标的一个关键应用是网络评估。
For 36 packets with 3 runs of 11 in-order packets, we have:
对于36个数据包（3次运行11个顺序数据包），我们有：
p = 36
x = 3
a = 33
q = 3 * (11*11) = 363
ave. reordering-free run = 11
q/a = 11
(q/a)/(a/x) = 1.0
p = 36
x = 3
a = 33
q = 3 * (11*11) = 363
ave. reordering-free run = 11
q/a = 11
(q/a)/(a/x) = 1.0
For 36 packets with 3 runs, 2 runs of length 1, and one of length 31, we have:
对于36个数据包，3次运行，2次运行长度为1，一次运行长度为31，我们有：
p = 36
x = 3
a = 33
q = 1 + 1 + 961 = 963
ave. reordering-free run = 11
q/a = 29.18
(q/a)/(a/x) = 2.65
p = 36
x = 3
a = 33
q = 1 + 1 + 961 = 963
ave. reordering-free run = 11
q/a = 29.18
(q/a)/(a/x) = 2.65
The variability in run length is prominent in the difference between the q values (sum of the squared run lengths) and in comparing average run length to the (q/a)/(a/x) ratios (equals 1 when all runs are the same length).
游程长度的可变性突出表现在q值之间的差异（游程长度的平方和）以及将平均游程长度与（q/a）/（a/x）比率进行比较（当所有游程长度相同时等于1）。
This section describes a metric that conveys information associated with the effect of reordering on TCP. However, in order to infer anything about TCP performance, the test stream MUST bear a close resemblance to the TCP sender of interest. [RFC3148] lists the specific aspects of congestion control algorithms that must be specified. Further, RFC 3148 recommends that Bulk Transfer Capacity metrics SHOULD have instruments to distinguish three cases of packet reordering (in Section 3.3). The sample metrics defined above satisfy the requirements to classify packets that are slightly or grossly out-of-order. The metric in this section adds the capability to estimate whether reordering might cause the DUP-ACK threshold to be exceeded causing the Fast Retransmit algorithm to be invoked. Additional TCP Kernel Instruments are summarized in [Mat03].
本节描述了一个度量，它传递与TCP上重新排序的影响相关的信息。然而，为了推断TCP性能，测试流必须与感兴趣的TCP发送者非常相似。[RFC3148]列出了必须指定的拥塞控制算法的具体方面。此外，RFC 3148建议大容量传输容量指标应具有区分三种数据包重新排序情况的工具（见第3.3节）。上面定义的样本度量满足对稍微或严重无序的数据包进行分类的要求。本节中的度量增加了估计重新排序是否会导致超过DUP-ACK阈值，从而导致调用快速重传算法的能力。[Mat03]中总结了其他TCP内核工具。
Type-P-Packet-n-Reordering-Stream
类型P-Packet-n-Reordering-Stream
Let n be a positive integer (a parameter). Let k be a positive integer equal to the number of packets sent (sample size). Let l be a non-negative integer representing the number of packets that were received out of the k packets sent. (Note that there is no relationship between k and l: on one hand, losses can make l less than k; on the other hand, duplicates can make l greater than k.) Assign each sent packet a sequence number, 1 to k, in order of packet emission.
设n为正整数（一个参数）。设k为正整数，等于发送的数据包数（样本大小）。设l为非负整数，表示发送的k个数据包中接收到的数据包数。（注意，k和l之间没有关系：一方面，丢失会使l小于k；另一方面，重复会使l大于k。）按数据包发射的顺序为每个发送的数据包分配一个序列号，1到k。
Let s[1], s[2], ..., s[l] be the original sequence numbers of the received packets, in the order of arrival.
设s[1]、s[2]、…、s[l]为接收数据包的原始序列号，按到达顺序排列。
Definition 1: Received packet number i (n < i <= l), with source sequence number s[i], is n-reordered if and only if for all j such that i-n <= j < i, s[j] > s[i].
定义1：源序列号为s[i]的接收包编号i（n<i<=l）被n重排序当且仅当对于所有j使得i-n<=j<i，s[j]>s[i]。
Claim: If, by this definition, a packet is n-reordered and 0 < n' < n, then the packet is also n'-reordered.
声明：根据这个定义，如果一个数据包是n-重排序的，并且0<n'<n，那么该数据包也是n-重排序的。
Note: This definition is illustrated by C code in Appendix A. The code determines and reports the n-reordering for n from 1 to a specified parameter (MAXN in the code, set to 100). The value of n conjectured to be relevant for TCP is the TCP duplicate ACK threshold (set to the value of 3 by paragraph 2 of Section 3.2 of [RFC 2581]).
注：附录A中的C代码说明了该定义。该代码确定并报告了n从1到指定参数的n重排序（代码中的MAXN，设置为100）。推测与TCP相关的n值是TCP重复确认阈值（根据[RFC 2581]第3.2节第2段设置为3）。
This definition does not assign an n to all reordered packets as defined by the singleton metric, in particular when blocks of successive packets are reordered. (In the arrival sequence s={1,2,3,7,8,9,4,5,6}, packets 4, 5, and 6 are reordered, but only packet 4 is n-reordered, with n=3.)
该定义没有将n分配给由单例度量定义的所有重新排序的数据包，特别是当连续数据包的块被重新排序时。（在到达序列s={1,2,3,7,8,9,4,5,6}中，数据包4、5和6被重新排序，但只有数据包4被重新排序，其中n=3。）
Definition 2: The degree of n-reordering of a sample is m/l, where m is the number of n-reordered packets in the sample.
定义2：样本的n重排序程度为m/l，其中m是样本中n重排序数据包的数量。
Definition 3: The degree of monotonic reordering of a sample is its degree of 1-reordering.
定义3：样本的单调重排序度是其1-重排序度。
Definition 4: A sample is said to have no reordering if its degree of monotonic reordering is 0.
定义4：如果样本的单调重排序度为0，则称其没有重排序。
Note: As follows from the claim above, if monotonic reordering of a sample is 0, then the n-reordering of the sample is 0 for all n.
注：如上所述，如果一个样本的单调重排序为0，那么对于所有n个样本，样本的n重排序为0。
The degree of n-reordering may be expressed as a percentage, in which case the number from Definition 2 is multiplied by 100.
n-重新排序的程度可以表示为百分比，在这种情况下，定义2中的数字乘以100。
The n-reordering metric is helpful for matching the duplicate ACK threshold setting to a given path. For example, if a path exhibits no more than 5-reordering, a DUP-ACK threshold of 6 may avoid unnecessary retransmissions.
n重排序度量有助于将重复确认阈值设置与给定路径匹配。例如，如果路径显示的重排序不超过5，则DUP-ACK阈值为6可以避免不必要的重传。
Important special cases are n=1 and n=3:
重要的特殊情况有n=1和n=3：
- For n=1, absence of 1-reordering means the sequence numbers that the receiver sees are monotonically increasing with respect to the previous arriving packet.
- 对于n＝1，缺少1-重新排序意味着接收机看到的序列号相对于先前到达的分组单调增加。
- For n=3, a NewReno TCP sender would retransmit 1 packet in response to an instance of 3-reordering and therefore consider this packet lost for the purposes of congestion control (the sender will halve its congestion window, see [RFC2581]). Three is the default threshold for Stream Control Transport Protocol (SCTP) [RFC2960], and the Datagram Congestion Control Protocol (DCCP) [RFC4340] when used with Congestion Control ID 2: TCP-like Congestion Control [RFC4341].
- 对于N＝3，NeReNeN-TCP发送器将响应1重排序的实例重发1个分组，因此考虑该分组对于拥塞控制的目的而丢失（发送方将使其拥塞窗口减半，参见[RCF2581]）。三是流控制传输协议（SCTP）[RFC2960]和数据报拥塞控制协议（DCCP）[RFC4340]在与拥塞控制ID 2:TCP类拥塞控制[RFC4341]一起使用时的默认阈值。
A sample's n-reordering may be expressed as a histogram to summarize the frequency for each value of n.
样本的n-重新排序可以表示为直方图，以总结每个n值的频率。
We note that the definition of n-reordering cannot predict the exact number of packets unnecessarily retransmitted by a TCP sender under some circumstances, such as cases with closely-spaced reordered singletons. Both time and position influence the sender's behavior.
我们注意到，在某些情况下，n-重新排序的定义无法预测TCP发送方不必要地重新传输的数据包的确切数量，例如具有紧密间隔的重新排序单例的情况。时间和位置都会影响发送者的行为。
A packet's n-reordering designation is sometimes equal to its reordering extent, e. n-reordering is different in the following ways:
数据包的n重排序指定有时等于其重排序范围，即。n-重新排序在以下方面有所不同：
1. n is a count of early packets with consecutive arrival positions at the receiver.
1. n是在接收器处具有连续到达位置的早期分组的计数。
2. Reordered packets (Type-P-Reordered=TRUE) may not be n-reordered, but will have an extent, e (see the examples).
2. 重新排序的数据包（Type-P-Reordered=TRUE）可能不是n-Reordered，但会有一个区段e（参见示例）。
The results of tests will be dependent on the time interval between measurement packets (both at the source, and during transport where spacing may change). Clearly, packets launched infrequently (e.g., 1 per 10 seconds) are unlikely to be reordered.
测试结果将取决于测量数据包之间的时间间隔（在源位置，以及在间隔可能改变的传输过程中）。显然，不经常发送的数据包（例如，每10秒1个）不太可能被重新排序。
In order to gauge the reordering for an application according to the metrics defined in this memo, it is RECOMMENDED to use the same sending pattern as the application of interest. In any case, the exact method of packet generation MUST be reported with the measurement results, including all stream parameters.
为了根据本备忘录中定义的指标衡量应用程序的重新排序，建议使用与感兴趣的应用程序相同的发送模式。在任何情况下，包生成的确切方法必须与测量结果一起报告，包括所有流参数。
+ To make inferences about applications that use TCP, it is REQUIRED to use TCP-like Streams as in [RFC3148]
+ 要推断使用TCP的应用程序，需要使用类似TCP的流，如[RFC3148]
+ For real-time applications, it is RECOMMENDED to use periodic streams as in [RFC3432]
+ 对于实时应用，建议使用[RFC3432]中的周期流
It is acceptable to report the metrics of Sections 3 and 4 with other IPPM metrics using Poisson streams [RFC2330]. Poisson streams represent an "unbiased sample" of network performance for packet loss and delay metrics. However, it would be incorrect to make inferences about the application categories above using reordering metrics measured with Poisson streams.
可以使用泊松流[RFC2330]报告第3节和第4节的指标以及其他IPPM指标。泊松流表示网络性能的“无偏样本”，用于分组丢失和延迟度量。但是，使用泊松流度量的重新排序度量来推断上述应用程序类别是不正确的。
Test stream designers may prefer to use a periodic sending interval in order to maintain a known temporal bias and allow simplified results analysis (as described in [RFC3432]). In this case, it is RECOMMENDED that the periodic sending interval be chosen to reproduce the closest source packet spacing expected. Testers must recognize that streams sent at the link speed serialization limit MUST have limited duration and MUST consider packet loss an indication that the stream has caused congestion, and suspend further testing.
测试流设计者可能更喜欢使用周期性发送间隔，以保持已知的时间偏差，并允许简化结果分析（如[RFC3432]中所述）。在这种情况下，建议选择周期性发送间隔以再现预期的最近源分组间隔。测试人员必须认识到，在链路速度序列化限制下发送的流必须具有有限的持续时间，并且必须考虑分组丢失指示流已经导致拥塞，并暂停进一步的测试。
When intending to compare independent measurements of reordering, it is RECOMMENDED to use the same test stream parameters in each measurement system.
当打算比较重新排序的独立测量时，建议在每个测量系统中使用相同的测试流参数。
Packet lengths might also be varied to attempt to detect instances of parallel processing (they may cause steady state reordering). For example, a line-speed burst of the longest (MTU-length) packets followed by a burst of the shortest possible packets may be an effective detecting pattern. Other size patterns are possible.
数据包长度也可以改变，以尝试检测并行处理的实例（它们可能导致稳态重新排序）。例如，最长（MTU长度）分组的线速突发随后是最短可能分组的突发可以是有效的检测模式。其他尺寸模式也是可能的。
The non-reversing order criterion and all metrics described above remain valid and useful when a stream of packets experiences packet loss, or both loss and reordering. In other words, losses alone do not cause subsequent packets to be declared reordered.
当数据包流经历数据包丢失或丢失和重新排序时，上述非反转顺序标准和所有度量仍然有效和有用。换句话说，丢失本身不会导致随后的数据包被声明为重新排序。
Since this metric definition may use sequence numbers with finite range, it is possible that the sequence numbers could reach end-of-range and roll over to zero during a measurement. By definition, the NextExp value cannot decrease, and all packets received after a rollover would be declared reordered. Sequence number rollover can be avoided by using combinations of counter size and test duration where rollover is impossible (and sequence is reset to zero at the start). Also, message-based numbering results in slower sequence consumption. There may still be cases where methodological mitigation of this problem is desirable (e.g., long-term testing). The elements of mitigation are:
由于该度量定义可能使用有限范围内的序列号，因此在测量过程中，序列号可能达到范围末端并滚动到零。根据定义，NextExp值不能减少，并且在滚动后接收的所有数据包都将被声明为重新排序。在不可能翻转的情况下（并且序列在开始时重置为零），可以通过使用计数器大小和测试持续时间的组合来避免序列号翻转。此外，基于消息的编号会导致较慢的序列消耗。在某些情况下，从方法上缓解这一问题仍然是可取的（例如，长期测试）。缓解措施的要素包括：
1. There must be a test to detect if a rollover has occurred. It would be nearly impossible for the sequence numbers of successive packets to jump by more than half the total range, so these large discontinuities are designated as rollover.
1. 必须进行测试以检测是否发生了翻车。连续数据包的序列号几乎不可能跳转超过总范围的一半，因此这些大的不连续性被指定为滚动。
2. All sequence numbers used in computations are represented in a sufficiently large precision. The numbers have a correction applied (equivalent to adding a significant digit) whenever rollover is detected.
2. 计算中使用的所有序列号都以足够高的精度表示。每当检测到翻滚时，这些数字都会应用一个校正（相当于添加一个有效数字）。
3. Reordered packets coincident with sequence numbers reaching end-of-range must also be detected for proper application of correction factor.
3. Reordered packets coincident with sequence numbers reaching end-of-range must also be detected for proper application of correction factor.translate error, please retry
Ideally, the test instrument would have the ability to use all earlier packets at any point in the test stream. In practice, there will be limited ability to determine the extent of reordering, due to the storage requirements for previous packets. Saving only packets that indicate discontinuities (and their arrival positions) will reduce storage volume.
理想情况下，测试仪器能够在测试流中的任何点使用所有早期数据包。实际上，由于以前数据包的存储要求，确定重新排序范围的能力有限。仅保存指示不连续性（及其到达位置）的数据包将减少存储量。
Another solution is to use a sliding history window of packets, where the window size would be determined by an upper bound on the useful reordering extent. This bound could be several packets or several seconds worth of packets, depending on the intended analysis. When discarding all stream information beyond the window, the reordering extent or degree of n-reordering may need to be expressed as greater than the window length if the reordering discontinuity information has been discarded, and Gap calculations would not be possible.
另一种解决方案是使用数据包的滑动历史窗口，其中窗口大小由有用的重新排序范围的上限确定。根据预期的分析，该界限可以是几个数据包或几秒钟的数据包。当丢弃窗口之外的所有流信息时，如果已丢弃重新排序的不连续信息，则可能需要将重新排序的范围或n-重新排序的程度表示为大于窗口长度，并且不可能进行间隙计算。
The requirement to ignore duplicate packets also mandates storage. Here, tracking the sequence numbers of missing packets may minimize storage size. Missing packets may eventually be declared lost or be reordered if they arrive. The missing packet list and the largest sequence number received thus far (NextExp - 1) are sufficient information to determine if a packet is a duplicate (assuming a manageable storage size for packets that are missing due to loss).
忽略重复数据包的要求也要求存储。这里，跟踪丢失包的序列号可以最小化存储大小。丢失的数据包最终可能会被宣布丢失，或者在到达时被重新排序。丢失的数据包列表和到目前为止接收到的最大序列号（NextExp-1）是确定数据包是否重复的足够信息（假设由于丢失而丢失的数据包具有可管理的存储大小）。
It is important to note that practical IP networks also have limited ability to "store" packets, even when routing loops appear temporarily. Therefore, the maximum storage for reordering metrics (and their complexity) would only approach the number packets in the sample, K, when the sending time for K packets is small with respect to the network's largest possible transfer time. Another possible limitation on storage is the maximum length of the sequence number field, assuming that most test streams do not exhaust this length in practice.
重要的是要注意，实际的IP网络“存储”数据包的能力也有限，即使在临时出现路由循环时也是如此。因此，当K个分组的发送时间相对于网络的最大可能传输时间较小时，用于重新排序度量的最大存储（及其复杂性）将仅接近样本中的分组数K。另一个可能的存储限制是序列号字段的最大长度，假设大多数测试流在实践中没有耗尽该长度。
Last, we note that determining reordering extents and gaps is tricky when there are overlapped or nested events. Test instrument complexity and reordering complexity are directly correlated.
最后，我们注意到，当存在重叠或嵌套事件时，确定重新排序的范围和间隔是很棘手的。测试仪器复杂度和重新排序复杂度直接相关。
As with other IPPM metrics, the definitions have been constructed primarily for Active measurements.
与其他IPPM度量一样，这些定义主要针对活动度量。
Assuming that the necessary sequence information (message number) is included in the packet payload (possibly in application headers such as RTP), reordering metrics may be evaluated in a passive measurement arrangement. Also, it is possible to evaluate order at any point along a source-destination path, recognizing that intermediate measurements may differ from those made at the destination (where the reordering effect on applications can be inferred).
假设必要的序列信息（消息编号）包括在分组有效载荷中（可能在诸如RTP的应用报头中），可以在被动测量安排中评估重新排序度量。此外，还可以评估源-目的地路径上任何点的顺序，认识到中间测量可能不同于在目的地进行的测量（可以推断应用程序的重新排序影响）。
It is possible to apply these metrics to evaluate reordering in a TCP sender's stream. In this case, the source sequence numbers would be based on byte stream or segment numbering. Since the stream may include retransmissions due to loss or reordering, care must be taken to avoid declaring retransmitted packets reordered. The additional sequence reference of s or SrcTime helps avoid this ambiguity in active measurement, or the optional TCP timestamp field [RFC1323] in passive measurement.
可以应用这些度量来评估TCP发送方流中的重新排序。在这种情况下，源序列号将基于字节流或段编号。由于流可能包括由于丢失或重新排序而导致的重新传输，因此必须注意避免声明重新传输的分组已重新排序。s或SrcTime的附加序列参考有助于避免主动测量中的这种模糊性，或被动测量中的可选TCP时间戳字段[RFC1323]。
This section provides some examples to illustrate how the non-reversing order criterion works, how n-reordering works in comparison, and the value of quantifying reordering in all the dimensions of time, bytes, and position.
本节提供了一些示例来说明非反转顺序标准是如何工作的，n-重新排序在比较中是如何工作的，以及在时间、字节和位置的所有维度中量化重新排序的值。
Throughout this section, we will refer to packets by their source sequence number, except where noted. So "Packet 4" refers to the packet with source sequence number 4, and the reader should refer to the tables in each example to determine packet 4's arrival index number, if needed.
在本节中，我们将根据数据包的源序列号引用数据包，除非另有说明。因此，“包4”是指源序列号为4的包，如果需要，读取器应该参考每个示例中的表来确定包4的到达索引号。
Table 1 gives a simple case of reordering, where one packet is reordered, Packet 4. Packets are listed according to their arrival, and message numbering is used. All packets contain PayloadSize=100 bytes, with SrcByte=(s x 100)-99 for s=1,2,3,4,...
表1给出了一个简单的重新排序情况，其中一个数据包被重新排序，即数据包4。根据数据包的到达列出数据包，并使用消息编号。所有数据包都包含PayloadSize=100字节，对于s=1,2,3,4，…，SrcByte=（s x 100）-99，。。。
Table 1: Example with Packet 4 Reordered,
Sending order( s @Src): 1,2,3,4,5,6,7,8,9,10
Table 1: Example with Packet 4 Reordered,
Sending order( s @Src): 1,2,3,4,5,6,7,8,9,10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
5 4 80 148 68 -82 4
6 6 100 168 68 0 5
7 7 120 188 68 0 6
8 8 140 208 68 0 7
4 9 60 210 150 82 8 400 62
9 9 160 228 68 0 9
10 10 180 248 68 0 10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
5 4 80 148 68 -82 4
6 6 100 168 68 0 5
7 7 120 188 68 0 6
8 8 140 208 68 0 7
4 9 60 210 150 82 8 400 62
9 9 160 228 68 0 9
10 10 180 248 68 0 10
Each column gives the following information:
每列提供以下信息：
s Packet sequence number at the source. NextExp The value of NextExp when the packet arrived (before update). SrcTime Packet time stamp at the source, ms. DstTime Packet time stamp at the destination, ms. Delay 1-way delay of the packet, ms. IPDV IP Packet Delay Variation, ms IPDV = Delay(SrcNum)-Delay(SrcNum-1) DstOrder Order in which the packet arrived at the destination. Byte Offset The byte offset of a reordered packet, in bytes. LateTime The lateness of a reordered packet, in ms.
s源处的数据包序列号。NextExp数据包到达时（更新前）NextExp的值。源的SrcTime数据包时间戳，目的地的ms.DstTime数据包时间戳，数据包的ms.Delay单向延迟，ms.IPDV IP数据包延迟变化，ms IPDV=延迟（SrcNum）-延迟（SrcNum-1）数据包到达目的地的顺序。字节偏移量重新排序的数据包的字节偏移量，以字节为单位。LateTime重新排序的数据包的延迟，以毫秒为单位。
We can see that when Packet 4 arrives, NextExp=9, and it is declared reordered. We compute the extent of reordering as follows:
我们可以看到，当数据包4到达时，NextExp=9，它被声明为重新排序。我们计算重新排序的范围如下：
Using the notation <s[1], ..., s[i], ..., s[L]>, the received packets are represented as:
使用符号<s[1]、…、s[i]、…、s[L]>，接收的分组表示为：
\/ s = 1, 2, 3, 5, 6, 7, 8, 4, 9, 10 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 /\
\/s=1,2,3,5,6,7,8,4,9,10 i=1,2,3,4,5,6,7,8,9,10/\
Applying the definition of Type-P-Packet-Reordering-Extent-Stream:
应用类型P-Packet-Reordering-Extent-Stream的定义：
when j=7, 8 > 4, so the reordering extent is 1 or more. when j=6, 7 > 4, so the reordering extent is 2 or more. when j=5, 6 > 4, so the reordering extent is 3 or more. when j=4, 5 > 4, so the reordering extent is 4 or more.
当j=7时，8>4，因此重新排序范围为1或更多。当j=6时，7>4，因此重新排序范围为2或更多。当重新排序=6时，范围大于等于4。当j=4时，5>4，因此重新排序范围为4或更多。
when j=3, but 3 < 4, and 4 is the maximum extent, e=4 (assuming there are no earlier sequence discontinuities, as in this example).
当j=3，但3<4，且4为最大范围时，e=4（假设没有早期序列不连续，如本例所示）。
Further, we can compute the Late Time (210-148=62ms using DstTime) compared to Packet 5's arrival. If the receiver has a de-jitter buffer that holds more than 4 packets, or at least 62 ms storage, Packet 4 may be useful. Note that 1-way delay and IPDV indicate unusual behavior for Packet 4. Also, if Packet 4 had arrived at least 62ms earlier, it would have been in-order in this example.
此外，我们可以计算与数据包5到达相比的延迟时间（210-148=62ms，使用DstTime）。如果接收机具有保存超过4个分组或至少62ms存储器的去抖动缓冲器，则分组4可能是有用的。请注意，单向延迟和IPDV表示数据包4的异常行为。此外，如果数据包4至少提前62毫秒到达，则在本例中它将是有序的。
If all packets contained 100 byte payloads, then Byte Offset is equal to 400 bytes.
如果所有数据包都包含100字节的有效负载，则字节偏移量等于400字节。
Following the definitions of Section 5.1, Packet 4 is designated 4-reordered.
根据第5.1节的定义，数据包4被指定为4-重新排序。
Table 2 Example with Packets 5 and 6 Reordered, Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10
表2数据包5和6重新排序的示例，发送顺序（s@Src）：1,2,3,4,5,6,7,8,9,10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
4 4 60 128 68 0 4
7 5 120 188 68 -22 5
5 8 80 189 109 41 6 100 1
6 8 100 190 90 -19 7 100 2
8 8 140 208 68 0 8
9 9 160 228 68 0 9
10 10 180 248 68 0 10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
4 4 60 128 68 0 4
7 5 120 188 68 -22 5
5 8 80 189 109 41 6 100 1
6 8 100 190 90 -19 7 100 2
8 8 140 208 68 0 8
9 9 160 228 68 0 9
10 10 180 248 68 0 10
Table 2 shows a case where Packets 5 and 6 arrive just behind Packet 7, so both 5 and 6 are reordered. The Late times (189-188=1, 190-188=2) are small.
表2显示了一种情况，其中数据包5和6正好在数据包7之后到达，因此5和6都被重新排序。晚期（189-188=1190-188=2）很小。
Using the notation <s[1], ..., s[i], ..., s[l]>, the received packets are represented as:
使用符号<s[1]、…、s[i]、…、s[l]>，接收的分组表示为：
\/ \/
s = 1, 2, 3, 4, 7, 5, 6, 8, 9, 10
i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
/\ /\
\/ \/
s = 1, 2, 3, 4, 7, 5, 6, 8, 9, 10
i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
/\ /\
Considering Packet 5 first:
首先考虑第5包：
when j=5, 7 > 5, so the reordering extent is 1 or more. when j=4, we have 4 < 5, so 1 is its maximum extent, and e=1.
当j=5时，7>5，因此重新排序范围为1或更多。当j=4时，我们有4<5，所以1是它的最大范围，e=1。
Considering Packet 6 next:
接下来考虑第6包：
when j=6, 5 < 6, the extent is not yet defined. when j=5, 7 > 6, so the reordering extent is i-j=2 or more. when j=4, 4 < 6, and we find 2 is its maximum extent, and e=2.
当j=6，5<6时，范围尚未定义。当j=5时，7>6，因此重新排序范围为i-j=2或更多。当j=4，4<6，我们发现2是它的最大范围，e=2。
We can also associate each of these reordered packets with a reordering discontinuity. We find the minimum j=5 (for both packets) according to Section 4.2.3. So Packet 6 is associated with the same reordering discontinuity as Packet 5, the Reordering Discontinuity at Packet 7.
我们还可以将这些重新排序的数据包中的每一个与重新排序的不连续性相关联。根据第4.2.3节，我们发现最小j=5（对于两个数据包）。因此，分组6与分组5相同的重新排序不连续性相关联，即分组7处的重新排序不连续性。
This is a case where reordering extent e would over-estimate the packet storage required to restore order. Only one packet storage is required (to hold Packet 7), but e=2 for Packet 6.
这种情况下，重新排序范围e将高估恢复顺序所需的数据包存储。只需要一个数据包存储器（保存数据包7），但数据包6的e=2。
Following the definitions of Section 5, Packet 5 is designated 1-reordered, but Packet 6 is not designated n-reordered.
根据第5节的定义，数据包5被指定为1-重新排序，但数据包6未被指定为n-重新排序。
A hypothetical sender/receiver pair may retransmit Packet 5 unnecessarily, since it is 1-reordered (in agreement with the singleton metric). Though Packet 6 may not be unnecessarily retransmitted, the receiver cannot advance Packet 7 to the higher layers until after Packet 6 arrives. Therefore, the singleton metric correctly determined that Packet 6 is reordered.
假设的发送方/接收方对可能不必要地重新传输包5，因为它是1重排序的（与单例度量一致）。尽管分组6可能不会被不必要地重新传输，但是在分组6到达之前，接收机不能将分组7推进到更高层。因此，单例度量正确地确定分组6被重新排序。
Table 3 Example with Packets 4, 5, and 6 reordered Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10,11
表3数据包4、5和6重新排序发送顺序（s@Src）的示例：1,2,3,4,5,6,7,8,9,10,11
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
7 4 120 188 68 -88 4
8 8 140 208 68 0 5
9 9 160 228 68 0 6
10 10 180 248 68 0 7
4 11 60 250 190 122 8 400 62
5 11 80 252 172 -18 9 400 64
6 11 100 256 156 -16 10 400 68
11 11 200 268 68 0 11
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
7 4 120 188 68 -88 4
8 8 140 208 68 0 5
9 9 160 228 68 0 6
10 10 180 248 68 0 7
4 11 60 250 190 122 8 400 62
5 11 80 252 172 -18 9 400 64
6 11 100 256 156 -16 10 400 68
11 11 200 268 68 0 11
The case in Table 3 is where three packets in sequence have long transit times (Packets with s = 4, 5, and 6). Delay, Late time, and Byte Offset capture this very well, and indicate variation in reordering extent, while IPDV indicates that the spacing between packets 4,5,and 6 has changed.
表3中的情况是，顺序中的三个数据包具有较长的传输时间（s=4、5和6的数据包）。延迟、延迟时间和字节偏移量很好地捕捉到了这一点，并指示重新排序范围的变化，而IPDV指示数据包4、5和6之间的间隔已经改变。
The histogram of Reordering extents (e) would be:
重新排序范围（e）的直方图为：
Bin 1 2 3 4 5 6 7 Frequency 0 0 0 1 1 1 0
储物箱1234567频率0 01 10
Using the notation <s[1], ..., s[i], ..., s[l]>, the received packets are represented as:
使用符号<s[1]、…、s[i]、…、s[l]>，接收的分组表示为：
s = 1, 2, 3, 7, 8, 9,10, 4, 5, 6, 11 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,11
s=1,2,3,7,8,9,10,4,5,6,11 i=1,2,3,4,5,6,7,8,9,10,11
We first calculate the n-reordering. Considering Packet 4 first:
我们首先计算n重排序。首先考虑第4包：
when n=1, 7<=j<8, and 10> 4, so the packet is 1-reordered. when n=2, 6<=j<8, and 9 > 4, so the packet is 2-reordered. when n=3, 5<=j<8, and 8 > 4, so the packet is 3-reordered. when n=4, 4<=j<8, and 7 > 4, so the packet is 4-reordered. when n=5, 3<=j<8, but 3 < 4, and 4 is the maximum n-reordering.
当n=1、7<=j<8、10>4时，数据包被1重排序。当n=2，6<=j<8，9>4时，数据包被2重排序。当n=3，5<=j<8，8>4时，数据包被3重排序。当n=4，4<=j<8，7>4时，数据包被4重排序。当n=5时，3<=j<8，但3<4，4是最大n重排序。
Considering packet 5[9] next: when n=1, 8<=j<9, but 4 < 5, so the packet at i=9 is not designated as n-reordered. We find the same result for Packet 6.
接下来考虑数据包5[9]：当n=1时，8<=j<9，但4<5，因此i=9处的数据包不被指定为n重排序。对于数据包6，我们发现了相同的结果。
We now consider whether reordered Packets 5 and 6 are associated with the same reordering discontinuity as Packet 4. Using the test of Section 4.2.3, we find that the minimum j=4 for all three packets. They are all associated with the reordering discontinuity at Packet 7.
现在我们考虑重新排序的分组5和6是否与分组4具有相同的重新排序不连续性。使用第4.2.3节的测试，我们发现所有三个数据包的最小j=4。它们都与包7处的重新排序不连续性有关。
This example shows again that the n-reordering definition identifies a single Packet (4) with a sufficient degree of n-reordering that might cause one unnecessary packet retransmission by the New Reno TCP sender (with DUP-ACK threshold=3 or 4). Also, the reordered arrival of Packets 5 and 6 will allow the receiver process to pass Packets 7 through 10 up the protocol stack (the singleton Type-P-Reordered = TRUE for Packets 5 and 6, and they are all associated with a single reordering discontinuity).
该示例再次显示，n重排序定义识别具有足够程度的n重排序的单个分组（4），该n重排序可能导致新的Reno TCP发送方进行一次不必要的分组重传（DUP-ACK阈值＝3或4）。此外，分组5和6的重新排序到达将允许接收器进程将分组7到10向上传递到协议栈（对于分组5和6，singleton Type-P-reordered＝TRUE，并且它们都与单个重新排序不连续性相关联）。
Table 4 Example with Multiple Packet Reordering Discontinuities Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
表4多个数据包重新排序不连续发送顺序（s@Src）的示例：1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
Discontinuity Discontinuity
|---------Gap---------|
s = 1, 2, 3, 6, 7, 4, 5, 8, 9, 10, 12, 13, 11, 14, 15, 16
i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
Discontinuity Discontinuity
|---------Gap---------|
s = 1, 2, 3, 6, 7, 4, 5, 8, 9, 10, 12, 13, 11, 14, 15, 16
i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
r = 1, 2, 3, 4, 5, 0, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, ... number of runs,n = 1 2 3 end r counts = 5 0 5 (These values are computed after the packet arrives.)
r=1,2,3,4,5,0,0,1,2,3,4,5,0,1,2,3。。。运行次数，n=1 2 3端r计数=5 0 5（这些值在数据包到达后计算。）
Packet 4 has extent e=2, Packet 5 has extent e=3, and Packet 11 has e=2. There are two different reordering discontinuities, one at Packet 6 (where j=4) and one at Packet 12 (where j'=11).
数据包4的区段e=2，数据包5的区段e=3，数据包11的区段e=2。存在两种不同的重新排序不连续性，一种在数据包6（其中j=4）处，另一种在数据包12（其中j'=11）处。
According to the definition of Reordering Gap
Gap(s[j']) = (j') - (j)
Gap(Packet 12) = (11) - (4) = 7
According to the definition of Reordering Gap
Gap(s[j']) = (j') - (j)
Gap(Packet 12) = (11) - (4) = 7
We also have three reordering-free runs of lengths 5, 0, and 5.
我们还有三个长度分别为5、0和5的重新排序自由行程。
The differences between these two multiple-event metrics are evident here. Gaps are the distance between sequence discontinuities that are subsequently defined as reordering discontinuities, while reordering-free runs capture the distance between reordered packets.
这两个多事件度量之间的差异在这里很明显。间隙是序列不连续之间的距离，随后定义为重新排序的不连续，而重新排序的自由行程捕获重新排序的数据包之间的距离。
This metric requires a stream of packets sent from one host (source) to another host (destination) through intervening networks. This method could be abused for denial-of-service attacks directed at destination and/or the intervening network(s).
此度量要求通过中间网络从一个主机（源）发送到另一个主机（目的地）的数据包流。此方法可能被滥用，用于针对目标和/或介入网络的拒绝服务攻击。
Administrators of the 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 between the participants may be cause for immediate rejection or discard of packets or other escalation procedures 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) 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. The likely consequences of packet injection are that the additional packets would be declared duplicates, or that the original packets would be seen as duplicates (if they arrive after the corresponding injected packets), causing invalid measurements on the injected packets.
可以识别特定分组或分组流是样本的一部分。利用在目的地和/或介入网络处的该知识，可以改变分组的处理（例如，增加或减少延迟），这可能会扭曲所测量的性能。还可以生成似乎是样本度量的一部分的附加数据包。这些额外的数据包可能会干扰样本测量的结果。分组注入的可能后果是，附加分组将被声明为重复分组，或者原始分组将被视为重复分组（如果它们在相应注入分组之后到达），从而导致注入分组上的无效测量。
The requirements for data collection resistance to interference by malicious parties and mechanisms to achieve such resistance are available in other IPPM memos. A set of requirements for a data collection protocol can be found in [RFC3763], and a protocol specification for the One-Way Active Measurement Protocol (OWAMP) is
其他IPPM备忘录中提供了数据收集抗恶意方干扰的要求以及实现这种抗干扰的机制。在[RFC3763]中可以找到数据采集协议的一组要求，并提供了单向主动测量协议（OWAMP）的协议规范
in [RFC4656]. The security considerations sections of the two OWAMP documents are extensive and should be consulted for additional details.
在[RFC4656]中。两份OWAMP文件中的安全注意事项章节内容广泛，应查阅更多详细信息。
Metrics defined in this memo have been registered in the IANA IPPM METRICS REGISTRY as described in initial version of the registry [RFC4148].
本备忘录中定义的指标已在IANA IPPM指标注册中心注册，如注册中心初始版本[RFC4148]所述。
IANA has registered the following metrics in the IANA-IPPM-METRICS-REGISTRY-MIB:
IANA已在IANA-IPPM-metrics-REGISTRY-MIB中注册了以下指标：
ietfReorderedSingleton OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Reordered"
REFERENCE
"Reference RFC 4737, Section 3"
::= { ianaIppmMetrics 34 }
ietfReorderedSingleton OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Reordered"
REFERENCE
"Reference RFC 4737, Section 3"
::= { ianaIppmMetrics 34 }
ietfReorderedPacketRatio OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Reordered-Ratio-Stream"
REFERENCE
"Reference RFC 4737, Section 4.1"
::= { ianaIppmMetrics 35 }
ietfReorderedPacketRatio OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Reordered-Ratio-Stream"
REFERENCE
"Reference RFC 4737, Section 4.1"
::= { ianaIppmMetrics 35 }
ietfReorderingExtent OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Extent-Stream"
REFERENCE
"Reference RFC 4737, Section 4.2"
::= { ianaIppmMetrics 36 }
ietfReorderingExtent OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Extent-Stream"
REFERENCE
"Reference RFC 4737, Section 4.2"
::= { ianaIppmMetrics 36 }
ietfReorderingLateTimeOffset OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Late-Time-Stream"
REFERENCE
"Reference RFC 4737, Section 4.3"
::= { ianaIppmMetrics 37 }
ietfReorderingLateTimeOffset OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Late-Time-Stream"
REFERENCE
"Reference RFC 4737, Section 4.3"
::= { ianaIppmMetrics 37 }
ietfReorderingByteOffset OBJECT-IDENTITY STATUS current DESCRIPTION
ietfReorderingByteOffset对象标识状态当前描述
"Type-P-Packet-Byte-Offset-Stream"
REFERENCE
"Reference RFC 4737, Section 4.4"
::= { ianaIppmMetrics 38 }
"Type-P-Packet-Byte-Offset-Stream"
REFERENCE
"Reference RFC 4737, Section 4.4"
::= { ianaIppmMetrics 38 }
ietfReorderingGap OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Gap-Stream"
REFERENCE
"Reference RFC 4737, Section 4.5"
::= { ianaIppmMetrics 39 }
ietfReorderingGap OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Gap-Stream"
REFERENCE
"Reference RFC 4737, Section 4.5"
::= { ianaIppmMetrics 39 }
ietfReorderingGapTime OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-GapTime-Stream"
REFERENCE
"Reference RFC 4737, Section 4.5"
::= { ianaIppmMetrics 40 }
ietfReorderingGapTime OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-GapTime-Stream"
REFERENCE
"Reference RFC 4737, Section 4.5"
::= { ianaIppmMetrics 40 }
ietfReorderingFreeRunx OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-x-numruns-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 41 }
ietfReorderingFreeRunx OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-x-numruns-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 41 }
ietfReorderingFreeRunq OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-q-squruns-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 42 }
ietfReorderingFreeRunq OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-q-squruns-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 42 }
ietfReorderingFreeRunp OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 43 }
ietfReorderingFreeRunp OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 43 }
ietfReorderingFreeRuna OBJECT-IDENTITY STATUS current DESCRIPTION
ietfReorderingFreeRuna对象标识状态当前描述
"Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 44 }
"Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 44 }
ietfnReordering OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-n-Reordering-Stream"
REFERENCE
"Reference RFC 4737, Section 5"
::= { ianaIppmMetrics 45 }
ietfnReordering OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-n-Reordering-Stream"
REFERENCE
"Reference RFC 4737, Section 5"
::= { ianaIppmMetrics 45 }
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.
[RFC3148]Mathis，M.和M.Allman，“定义经验批量传输容量指标的框架”，RFC 3148，2001年7月。
[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月。
[RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active Measurement Protocol (OWAMP) Requirements", RFC 3763, April 2004.
[RFC3763]Shalunov，S.和B.Teitelbaum，“单向主动测量协议（OWAMP）要求”，RFC 3763，2004年4月。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148]Stephan，E.“IP性能度量（IPPM）度量注册表”，BCP 108，RFC 4148，2005年8月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zeckauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zeckauskas，“单向主动测量协议（OWAMP）”，RFC 46562006年9月。
[Bel02] J. Bellardo and S. Savage, "Measuring Packet Reordering," Proceedings of the ACM SIGCOMM Internet Measurement Workshop 2002, November 6-8, Marseille, France.
[Bel02]J.Bellardo和S.Savage，“测量数据包重新排序”，2002年ACM SIGCOMM互联网测量研讨会论文集，11月6-8日，法国马赛。
[Ben99] J.C.R. Bennett, C. Partridge, and N. Shectman, "Packet Reordering is Not Pathological Network Behavior," IEEE/ACM Transactions on Networking, vol. 7, no. 6, pp. 789-798, December 1999.
[Ben99]J.C.R.Bennett，C.Partridge和N.Shectman，“数据包重新排序不是病态的网络行为”，IEEE/ACM网络交易，第7卷，第6期，第789-798页，1999年12月。
[Cia00] L. Ciavattone and A. Morton, "Out-of-Sequence Packet Parameter Definition (for Y.1540)", Contribution number T1A1.3/2000-047, October 30, 2000, http://home.comcast.net/~acmacm/IDcheck/0A130470.doc.
[Cia00]L.Ciavattone和A.Morton，“无序数据包参数定义（适用于Y.1540）”，投稿编号T1A1.3/2000-047，2000年10月30日，http://home.comcast.net/~acmacm/IDcheck/0A130470.doc。
[Cia03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized Active Measurements on a Tier 1 IP Backbone," IEEE Communications Mag., pp. 90-97, June 2003.
[Cia03]L.Ciavattone，A.Morton和G.Ramachandran，“第1层IP主干上的标准化主动测量”，IEEE通信杂志，第90-97页，2003年6月。
[I.356] ITU-T Recommendation I.356, "B-ISDN ATM layer cell transfer performance", March 2000.
[I.356]ITU-T建议I.356，“B-ISDN ATM层信元传输性能”，2000年3月。
[Jai02] S. Jaiswal et al., "Measurement and Classification of Out-of-Sequence Packets in a Tier-1 IP Backbone," Proceedings of the ACM SIGCOMM Internet Measurement Workshop 2002, November 6-8, Marseille, France.
[Jai02]S.Jaiswal等人，“一级IP主干网中无序数据包的测量和分类”，2002年ACM SIGCOMM互联网测量研讨会论文集，11月6-8日，法国马赛。
[Lou01] D. Loguinov and H. Radha, "Measurement Study of Low-bitrate Internet Video Streaming", Proceedings of the ACM SIGCOMM Internet Measurement Workshop 2001 November 1-2, 2001, San Francisco, USA.
D. Loguinov和H. Radha，“低比特率互联网视频流的测量研究”，ACM SIGCOMM互联网测量工作坊2001，十一月，1-2，2001，旧金山，USA.
[Mat03] M. Mathis, J. Heffner, and R. Reddy, "Web100: Extended TCP Instrumentation for Research, Education and Diagnosis", ACM Computer Communications Review, Vol 33, Num 3, July 2003, http://www.web100.org/docs/mathis03web100.pdf.
[Mat03]M.Mathis，J.Heffner和R.Reddy，“Web100：用于研究、教育和诊断的扩展TCP仪器”，ACM计算机通信评论，第33卷，Num 3，2003年7月，http://www.web100.org/docs/mathis03web100.pdf.
[Pax98] V. Paxson, "Measurements and Analysis of End-to-End Internet Dynamics," Ph.D. dissertation, U.C. Berkeley, 1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz.
[Pax98]V.Paxson，“端到端互联网动态的测量和分析”，博士。博士论文，加州大学伯克利分校，1997年，ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control ", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[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月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，RFC 43412006年3月。
[TBABAJ02] T. Banka, A. Bare, A. P. Jayasumana, "Metrics for Degree of Reordering in Packet Sequences", Proc. 27th IEEE Conference on Local Computer Networks, Tampa, FL, Nov. 2002.
[TBABAJ02]T.Banka，A.Bare，A.P.Jayasumana，“数据包序列中重新排序程度的度量”，Proc。第27届IEEE本地计算机网络会议，佛罗里达州坦帕，2002年11月。
[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2002.
[Y.1540]ITU-T建议Y.1540，“互联网协议数据通信服务-IP数据包传输和可用性性能参数”，2002年12月。
The authors would like to acknowledge many helpful discussions with Matt Zekauskas, Jon Bennett (who authored the sections on Reordering-Free Runs), and Matt Mathis. We thank David Newman, Henk Uijterwaal, Mark Allman, Vern Paxson, and Phil Chimento for their reviews and suggestions, and Michal Przybylski for sharing implementation experiences with us on the ippm-list. Anura Jayasumana and Nischal Piratla brought in recent work-in-progress [TBABAJ02]. We gratefully acknowledge the foundation laid by the authors of the IP performance framework [RFC2330].
作者希望感谢与Matt Zekauskas、Jon Bennett（他撰写了关于重新安排自由跑的章节）和Matt Mathis进行的许多有益的讨论。我们感谢David Newman、Henk Uijterwaal、Mark Allman、Vern Paxson和Phil Chimento的审查和建议，以及Michal Przybylski与我们分享ippm清单上的实施经验。Anura Jayasumana和Nischal Piratla带来了最近正在进行的工作[TBABAJ02]。我们衷心感谢IP性能框架[RCFC3030]的作者奠定的基础。
Appendix A. Example Implementations in C (Informative)
附录A.C语言的示例实现（资料性）
Two example c-code implementations of reordering definitions follow:
以下是重新排序定义的两个示例c代码实现：
Example 1 n-reordering ============================================
Example 1 n-reordering ============================================
#include <stdio.h>
#include <stdio.h>
#define MAXN 100
#定义最大值100
#define min(a, b) ((a) < (b)? (a): (b))
#define loop(x) ((x) >= 0? x: x + MAXN)
#define min(a, b) ((a) < (b)? (a): (b))
#define loop(x) ((x) >= 0? x: x + MAXN)
/*
* Read new sequence number and return it. Return a sentinel value
* of EOF (at least once) when there are no more sequence numbers.
* In this example, the sequence numbers come from stdin;
* in an actual test, they would come from the network.
*
*/
/*
* Read new sequence number and return it. Return a sentinel value
* of EOF (at least once) when there are no more sequence numbers.
* In this example, the sequence numbers come from stdin;
* in an actual test, they would come from the network.
*
*/
int
read_sequence_number()
{
int res, rc;
rc = scanf("%d\n", &res);
if (rc == 1) return res;
else return EOF;
}
int
read_sequence_number()
{
int res, rc;
rc = scanf("%d\n", &res);
if (rc == 1) return res;
else return EOF;
}
int
main()
{
int m[MAXN]; /* We have m[j-1] == number of
* j-reordered packets. */
int ring[MAXN]; /* Last sequence numbers seen. */
int r = 0; /* Ring pointer for next write. */
int l = 0; /* Number of sequence numbers read. */
int s; /* Last sequence number read. */
int j;
int
main()
{
int m[MAXN]; /* We have m[j-1] == number of
* j-reordered packets. */
int ring[MAXN]; /* Last sequence numbers seen. */
int r = 0; /* Ring pointer for next write. */
int l = 0; /* Number of sequence numbers read. */
int s; /* Last sequence number read. */
int j;
for (j = 0; j < MAXN; j++) m[j] = 0;
for (;(s = read_sequence_number())!= EOF;l++,r=(r+1)%MAXN) {
for (j=0; j<min(l, MAXN)&&s<ring[loop(r-j-1)];j++) m[j]++;
ring[r] = s;
}
for (j = 0; j < MAXN; j++) m[j] = 0;
for (;(s = read_sequence_number())!= EOF;l++,r=(r+1)%MAXN) {
for (j=0; j<min(l, MAXN)&&s<ring[loop(r-j-1)];j++) m[j]++;
ring[r] = s;
}
for (j = 0; j < MAXN && m[j]; j++)
printf("%d-reordering = %f%%\n", j+1, 100.0*m[j]/(l-j-1));
if (j == 0) printf("no reordering\n");
else if (j < MAXN) printf("no %d-reordering\n", j+1);
else printf("only up to %d-reordering is handled\n", MAXN);
exit(0);
}
for (j = 0; j < MAXN && m[j]; j++)
printf("%d-reordering = %f%%\n", j+1, 100.0*m[j]/(l-j-1));
if (j == 0) printf("no reordering\n");
else if (j < MAXN) printf("no %d-reordering\n", j+1);
else printf("only up to %d-reordering is handled\n", MAXN);
exit(0);
}
/* Example 2 singleton and n-reordering comparison =======
Author: Jerry Perser 7-2002 (mod by acm 12-2004)
Compile: $ gcc -o jpboth file.c
Usage: $ jpboth 1 2 3 7 8 4 5 6 (pkt sequence given on cmdline)
Note to cut/pasters: line 59 may need repair
*/
/* Example 2 singleton and n-reordering comparison =======
Author: Jerry Perser 7-2002 (mod by acm 12-2004)
Compile: $ gcc -o jpboth file.c
Usage: $ jpboth 1 2 3 7 8 4 5 6 (pkt sequence given on cmdline)
Note to cut/pasters: line 59 may need repair
*/
#include <stdio.h>
#include <stdio.h>
#define MAXN 100
#define min(a, b) ((a) < (b)? (a): (b))
#define loop(x) ((x) >= 0? x: x + MAXN)
#define MAXN 100
#define min(a, b) ((a) < (b)? (a): (b))
#define loop(x) ((x) >= 0? x: x + MAXN)
/* Global counters */
int receive_packets=0; /* number of received */
int reorder_packets_Al=0; /* num reordered pkts (singleton) */
int reorder_packets_Stas=0; /* num reordered pkts(n-reordering)*/
/* Global counters */
int receive_packets=0; /* number of received */
int reorder_packets_Al=0; /* num reordered pkts (singleton) */
int reorder_packets_Stas=0; /* num reordered pkts(n-reordering)*/
/* function to test if current packet has been reordered
* returns 0 = not reordered
* 1 = reordered
*/
int testorder1(int seqnum) // Al
{
static int NextExp = 1;
int iReturn = 0;
/* function to test if current packet has been reordered
* returns 0 = not reordered
* 1 = reordered
*/
int testorder1(int seqnum) // Al
{
static int NextExp = 1;
int iReturn = 0;
if (seqnum >= NextExp) {
NextExp = seqnum+1;
} else {
iReturn = 1;
}
return iReturn;
}
if (seqnum >= NextExp) {
NextExp = seqnum+1;
} else {
iReturn = 1;
}
return iReturn;
}
int testorder2(int seqnum) // Stanislav
{
static int ring[MAXN]; /* Last sequence numbers seen. */
static int r = 0; /* Ring pointer for next write */
int testorder2(int seqnum) // Stanislav
{
static int ring[MAXN]; /* Last sequence numbers seen. */
static int r = 0; /* Ring pointer for next write */
int l = 0; /* Number of sequence numbers read. */
int j;
int iReturn = 0;
int l = 0; /* Number of sequence numbers read. */
int j;
int iReturn = 0;
l++;
r = (r+1) % MAXN;
for (j=0; j<min(l, MAXN) && seqnum<ring[loop(r-j-1)]; j++)
iReturn = 1;
ring[r] = seqnum;
return iReturn;
}
int main(int argc, char *argv[])
{
int i, packet;
for (i=1; i< argc; i++) {
receive_packets++;
packet = atoi(argv[i]);
reorder_packets_Al += testorder1(packet); // singleton
reorder_packets_Stas += testorder2(packet); //n-reord.
}
printf("Received packets = %d, Singleton Reordered = %d, n-
reordered = %d\n", receive_packets, reorder_packets_Al,
reorder_packets_Stas );
exit(0);
}
l++;
r = (r+1) % MAXN;
for (j=0; j<min(l, MAXN) && seqnum<ring[loop(r-j-1)]; j++)
iReturn = 1;
ring[r] = seqnum;
return iReturn;
}
int main(int argc, char *argv[])
{
int i, packet;
for (i=1; i< argc; i++) {
receive_packets++;
packet = atoi(argv[i]);
reorder_packets_Al += testorder1(packet); // singleton
reorder_packets_Stas += testorder2(packet); //n-reord.
}
printf("Received packets = %d, Singleton Reordered = %d, n-
reordered = %d\n", receive_packets, reorder_packets_Al,
reorder_packets_Stas );
exit(0);
}
Reference
参考
ISO/IEC 9899:1999 (E), as amended by ISO/IEC 9899:1999/Cor.1:2001 (E). Also published as:
ISO/IEC 9899:1999（E），经ISO/IEC 9899:1999/Cor.1:2001（E）修订。也出版为：
The C Standard: Incorporating Technical Corrigendum 1, British Standards Institute, ISBN: 0-470-84573-2, Hardcover, 558 pages, September 2003.
《C标准：合并技术勘误表1》，英国标准协会，ISBN:0-470-84573-2，精装本，558页，2003年9月。
Appendix B. Fragment Order Evaluation (Informative)
附录B.碎片顺序评估（资料性）
Section 3 stated that fragment reassembly is assumed prior to order evaluation, but that similar procedures could be applied prior to reassembly. This appendix gives definitions and procedures to identify reordering in a packet stream that includes fragmentation.
第3节指出，在订单评估之前，假设碎片重新组装，但在重新组装之前，可以采用类似的程序。本附录给出了定义和程序，以识别包含碎片的数据包流中的重新排序。
The Metric retains the same name, Type-P-Reordered, but additional parameters are required.
度量保留相同的名称，类型为-P-重新排序，但需要其他参数。
This appendix assumes that the device that divides a packet into fragments sends them according to ascending fragment offset. Early Linux OS sent fragments in reverse order, so this possibility is worth checking.
本附录假设将数据包分成片段的设备根据递增片段偏移量发送数据包。早期的Linux操作系统以相反的顺序发送片段，因此这种可能性值得检查。
+ MoreFrag, the state of the More Fragments Flag in the IP header.
+ MoreFrag，IP头中的More Fragments标志的状态。
+ FragOffset, the offset from the beginning of a fragmented packet, in 8 octet units (also from the IP header).
+ FragOffset，从碎片数据包开始的偏移量，以8个八位字节为单位（也来自IP报头）。
+ FragSeq#, the sequence number from the IP header of a fragmented packet currently under evaluation for reordering. When set to zero, fragment evaluation is not in progress.
+ FragSeq#，当前正在评估重新排序的碎片数据包的IP头的序列号。当设置为零时，片段评估不会进行。
+ NextExpFrag, the next expected fragment offset at the destination, in 8 octet units. Set to zero when fragment evaluation is not in progress.
+ NextExpFrag，目标处的下一个预期碎片偏移量，以8个八位字节为单位。当片段评估未进行时，设置为零。
The packet sequence number, s, is assumed to be the same as the IP header sequence number. Also, the value of NextExp does not change with the in-order arrival of fragments. NextExp is only updated when a last fragment or a complete packet arrives.
假定分组序列号s与IP报头序列号相同。此外，nextextsp的值不会随着片段的顺序而改变。NextExp仅在最后一个片段或完整数据包到达时更新。
Note that packets with missing fragments MUST be declared lost, and the Reordering status of any fragments that do arrive MUST be excluded from sample metrics.
请注意，丢失片段的数据包必须声明为丢失，并且必须从样本度量中排除任何确实到达的片段的重新排序状态。
The value of Type-P-Reordered is typically false (the packet is in-order) when
当
* the sequence number s >= NextExp, AND
* 序列号s>=NextExp，以及
* the fragment offset FragOffset >= NextExpFrag
* 片段偏移量FragOffset>=nextextxpfrag
However, it is more efficient to define reordered conditions exactly and designate Type-P-Reordered as False otherwise.
但是，更有效的方法是准确地定义重新排序的条件，否则将Type-P-reordered指定为False。
The value of Type-P-Reordered is defined as True (the packet is reordered) under the conditions below. In these cases, the NextExp value does not change.
在以下条件下，Type-P-Reordered的值定义为True（数据包被重新排序）。在这些情况下，NextExp值不会更改。
Case 1: if s < NextExp
案例1：如果s<NextExp
Case 2: if s < FragSeq#
Case 2: if s < FragSeq#
Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag
Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag
This definition can also be illustrated in pseudo-code. A version of the code follows, and some simplification may be possible. Housekeeping for the new parameters will be challenging.
这个定义也可以用伪代码来说明。下面是代码的一个版本，可能会有一些简化。新参数的内务管理将具有挑战性。
NextExp=0;
NextExpFrag=0;
FragSeq#=0;
NextExp=0;
NextExpFrag=0;
FragSeq#=0;
while(packets arrive with s, MoreFrag, FragOffset)
{
if (s>=NextExp AND MoreFrag==0 AND s>=FragSeq#){
/* a normal packet or last frag of an in-order packet arrived */
NextExp = s+1;
FragSeq# = 0;
NextExpFrag = 0;
Reordering = False;
}
if (s>=NextExp AND MoreFrag==1 AND s>FragSeq#>=0){
/* a fragment of a new packet arrived, possibly with a
higher sequence number than the current fragmented packet */
FragSeq# = s;
NextExpFrag = FragOffset+1;
Reordering = False;
}
if (s>=NextExp AND MoreFrag==1 AND s==FragSeq#){
/* a fragment of the "current packet s" arrived */
while(packets arrive with s, MoreFrag, FragOffset)
{
if (s>=NextExp AND MoreFrag==0 AND s>=FragSeq#){
/* a normal packet or last frag of an in-order packet arrived */
NextExp = s+1;
FragSeq# = 0;
NextExpFrag = 0;
Reordering = False;
}
if (s>=NextExp AND MoreFrag==1 AND s>FragSeq#>=0){
/* a fragment of a new packet arrived, possibly with a
higher sequence number than the current fragmented packet */
FragSeq# = s;
NextExpFrag = FragOffset+1;
Reordering = False;
}
if (s>=NextExp AND MoreFrag==1 AND s==FragSeq#){
/* a fragment of the "current packet s" arrived */
if (FragOffset >= NextExpFrag){
NextExpFrag = FragOffset+1;
Reordering = False;
}
else{
Reordering = True; /* fragment reordered */
}
}
if (s>=NextExp AND MoreFrag==1 AND s < FragSeq#){
/* case where a late fragment arrived,
for illustration only, redundant with else below */
Reordering = True;
}
else { /* when s < NextExp, or MoreFrag==0 AND s < FragSeq# */
Reordering = True;
}
}
if (FragOffset >= NextExpFrag){
NextExpFrag = FragOffset+1;
Reordering = False;
}
else{
Reordering = True; /* fragment reordered */
}
}
if (s>=NextExp AND MoreFrag==1 AND s < FragSeq#){
/* case where a late fragment arrived,
for illustration only, redundant with else below */
Reordering = True;
}
else { /* when s < NextExp, or MoreFrag==0 AND s < FragSeq# */
Reordering = True;
}
}
A working version of the code would include a check to ensure that all fragments of a packet arrive before using the Reordered status further, such as in sample metrics.
代码的工作版本将包括一个检查，以确保在进一步使用重新排序状态（如样本度量）之前，数据包的所有片段都已到达。
All fragments with the same source sequence number are assigned the same source time.
具有相同源序列号的所有片段分配给相同的源时间。
Evaluation with byte stream numbering may be simplified if the fragment offset is simply added to the SourceByte of the first packet (with fragment offset = 0), keeping the 8 octet units of the offset in mind.
如果将片段偏移量简单地添加到第一个数据包的源字节（片段偏移量=0），并记住偏移量的8个八位字节单位，则可以简化字节流编号的计算。
Regarding this entire document or any portion of it (including the pseudo-code and C code), the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.
对于整个文档或其中的任何部分（包括伪代码和C代码），作者不作任何保证，也不对其使用造成的任何损坏负责。作者向任何人授予不可撤销的许可，允许其以任何方式使用、修改和分发该作品，但不得削弱任何其他人使用、修改和分发该作品的权利，前提是重新分发的衍生作品不包含误导性的作者或版本信息。衍生作品无需根据类似条款获得许可。
Authors' Addresses
作者地址
Al Morton AT&T Labs Room D3 - 3C06 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 1571 EMail: acmorton@att.com
美国新泽西州南米德尔顿劳雷尔大道200号艾尔莫顿AT&T实验室D3-3C06室07748美国电话+1732 420 1571电子邮件：acmorton@att.com
Len Ciavattone AT&T Labs Room A2 - 4G06 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 1239 EMail: lencia@att.com
Len Ciavattone AT&T实验室A2-4G06室美国新泽西州南米德尔顿劳雷尔大道200号07748电话+1 732 420 1239电子邮件：lencia@att.com
Gomathi Ramachandran AT&T Labs Room C4 - 3D22 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 2353 EMail: gomathi@att.com
Gomathi Ramachandran AT&T实验室C4-3D22室，地址：美国新泽西州南米德尔顿劳雷尔大道200号，邮编：07748电话+1 732 420 2353电子邮件：gomathi@att.com
Stanislav Shalunov Internet2 1000 Oakbrook DR STE 300 Ann Arbor, MI 48104 Phone: +1 734 995 7060 EMail: shalunov@internet2.edu
Stanislav Shalunov Internet2 1000 Oakbrook DR STE 300密歇根州安娜堡48104电话：+1 734 995 7060电子邮件：shalunov@internet2.edu
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton, OR 97008 USA Phone: +1 818 338 4112 EMail: jperser@veriwave.com
Jerry Perser Veriwave 8770 SW Nimbus Ave.Suite B Beaverton，或97008美国电话：+1 818 338 4112电子邮件：jperser@veriwave.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。