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
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が再順序付けされます。これは、「遅い」のパケットが並べ替え宣言された[Pax98]でPaxonの並べ替えの定義に相当します。代替的には、「早期」パケットの代わりに（実施例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.
*わずかに転送時間が異なる2つ（またはそれ以上）のパスは、単一のパケットストリームまたはフローをサポートする場合、より長いパス（複数可）を通過するパケットは、アウトオブオーダー到着することができます。複数のパスは、負荷分散を達成するために使用され得るか、または経路の不安定性から生じ得ます。
* 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.
上記路特性の1つ以上が連続して存在する場合、並べ替えは、定常状態に基づいて存在していてもよいです。定常状態の並べ替え条件は、典型的には、パケットのかなりの割合が並べ替えさせます。並べ替えのこの形態は、最も容易にテストパケット間の間隔を最小化することによって検出されます。過渡並べ替えが不安定ネットワークに応答して発生し得ます。一時的なルーティングループは、極端な並べ替えの期間を引き起こす可能性があります。この状態は、時には極端な相関で、並べ替えの時折のインスタンスと長く、イン・オーダのストリームによって特徴付けられます。しかし、我々は、例えば、最後のパケットまたはサンプル内の最初のパケットが目的地に最初に到着しても同様に可能性があり、完全にランダムな順序でパケット配信を期待してはいけません。実際のネットワークに展示としてこのように、我々は、パケットの到着順序の少なくとも最小限度を期待しています。
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:
定義は、以下の目標を満足するつもり：
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 a different receiver. If all the metrics defined below are reported, they give a wide-ranging view of reordering conditions.)
2.並べ替えの程度を定量化。受信手順は、プロトコルまたはアプリケーションによって異なるため（我々は、この目標を達成するためのメトリックの数を定義する。パケットの並び替えの効果は、これらの手順に応じて変化するので、一つの受信機の動作の重要な側面を定量化メトリックは、異なる受信機とは無関係とすることができます下記に定義されたすべてのメトリックが報告された場合は、それらを並べ替え条件の幅広い視野を与えます。）
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.
+このような受信機の設計やネットワークの特性、および興味のあるコミュニティの観点から魅力的な関連性などの1つのまたは複数のアプリケーションを、持っています。
+ 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:
並べ替えメトリックは、次の属性の1以上を有することが望ましいです。
+ 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]のように）周期的なストリームに固有のパラメータとして送信規律のパラメータセット、（[RFC3148]のように）TCPのようなストリーム、またはポアソンは（[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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 sender's algorithm and the sequence of identifiers so that the "next expected" can be determined.)
第二支持概念は、「次の予想される」パケット番号で格納された値です。通常の条件下では、予想される次の値（NextExp）は、メッセージ番号のシーケンスの前のパケットの数プラス1です。 （「次の期待される」と判断することができるように、一般的に、受信機は、送信者のアルゴリズムと識別子のシーケンスを再生します。）
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:
パケットsは（SrcTime、一度に送信される）NextExp値と比較することによって並べ替えされることが見出された場合、そのタイプP-順序変更= TRUE。以下に定義されるようにそうでなければ、= FALSEタイプP-順序変更：
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の場合、タイプP-並べ替えられの値は、<NextExp（パケットを再順序付けされる）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.
タイプP-並べ替えられの値がFALSEとして定義されている場合、S> = NextExp（パケットがインオーダーです）。この場合、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
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.
我々は、インオーダーのパケットのために2つの異なる状態を定義します。
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に関連付けられたシーケンスの不連続性があります。現在のいずれかの並べ替え、または失われた、欠落したパケットの数に等しいNextExp、 - 不連続の大きさがsです。
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;
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.
限りSrcTimesとSrcBytesはユニークで信頼性があるように、セクション3.3の定義で並べ替えをテストする時間またはペイロードバイトの代替寸法を使用することが可能です。シーケンスの不連続が容易に定義されたメッセージの番号を用いて検出されます。しかし、これは時間やバイトの大きさにそれほど単純ではありません。シーケンスの不連続性の定義が続くサンプルメトリックで重要な役割を果たしているので、これは別の次元のdetractorです。
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が未定義の場合（到着パケットが最初に成功した転送であるため）において、パケットは、インオーダー（タイプP-順序変更= 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.
このメトリックは、評価の前に、パケットのフラグメントの再構築を前提としています。原理的には、タイプP-順序変更パケットのフラグメントの間で並べ替えを評価するメトリックを使用することが可能であるが、各フラグメントは、ソースシーケンス情報が含まれている必要があります。詳細については、付録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]のように）、周期的なストリーム、または（[RFC3148]のように）TCPのようなストリームに固有なパラメータ、パケットサイズやサイズのパターン。そして、次：
+ 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.
Lを+、パケットの総数は、送信された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 )
/（L）R =（タイプP-順序変更= TRUEとパケット数）
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.
タイプP-比ストリーム順序変更がゼロである場合、さらなる再順序付けメトリックは、そのサンプルについて検査する必要はありません。したがって、このメトリックの値は、並べ替え、無料サンプルの結果を要約するシンプルな機能です。
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
タイプ-P-パケット並べ替え-程度ストリーム
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、（ソースにおける）パケット送信のためにK 1から連続した整数を割り当てられています。
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-順序変更= TRUE）を考えます。インデックスjの組は、（1 <= J <I）のように[I] [J]> Sだが存在します。
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]はI-N S [j]は> S Jの最小値を[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.
（上記の定義において同定S [J]）インデックスjを有するパケットがインデックスi（S [i]）とでパケットの関連付けられた並べ替え不連続です。この定義は、以下の形式化されています。
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-順序変更比ストリーム用に定義されたパラメータに加えて、我々は指定します：
+ DstTime, the time that each packet in the stream arrives at the destination, and may be associated with index i, or packet s[i]
+ DstTime、ストリーム内の各パケットが宛先に到達し、インデックス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）は、分{J | 1 <= jが<I}を満たすのS [j]が> S [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]がソースシーケンス内の先行するパケットに対して、パケットの遅延変動を与えることに留意されたいです。遅れと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.
損失や並べ替えの組み合わせはLateTimeメトリックに影響を与えます。到着順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
タイプ-P-パケットバイトオフセットストリーム
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
+ ByteOffset（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].
*送信シーケンス番号、Sは、[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:
並べ替えパケットS [i]は並べ替え範囲とEの場合：
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]）=合計[修飾パケット] =合計[PayloadSize（I-1におけるパケット修飾する場合）、PayloadSize（I-2のパケット修飾する場合）、... PayloadSize（I-Eにおけるパケット常に修飾）]
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]）=合計[Sのペイロード[J] S [J]> S [i]と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.
私たちは、パケットサイズが可変である場合は特に並べ替えによるバッファサイズの推定値は、テストパケットとそのサイズの間の間隔の観点から、テストストリームに大きく依存することに注意してください。これらおよび他の状況では、メトリックタイプ-P-パケットバイトオフセット気流を用いて格納されたパケットのペイロードサイズ（S）の点でオフセット特徴付けるために最も有用であろう。
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.
サンプルのByteOffset結果が並べ替えられたパケットを収容し、それに基づいてバッファのチューニングを可能にするために必要なバッファの長さの頻度を要約するヒストグラムとして表すことができます。収容され、並べ替え、パケットのパーセント対バッファサイズとCDFは有益かもしれません。
Type-P-Packet-Reordering-Gap-Stream Type-P-Packet-Reordering-GapTime-Stream
タイプP-パケット並べ替えギャップストリーム型P-パケット並べ替え-GapTimeストリーム
We use the same parameters defined earlier, but add the convention that index i' is greater than i, likewise j' > j, and define:
我々は以前に定義された同じパラメータを使用しますが、私はインデックス> J「は、同様にJ Iよりも大きい」という規則を追加し、定義します。
+ Gap(s[j']), the Reordering Gap of packet s[j'] in units of integer messages
+ギャップ（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]>秒間Jの最小値（1 <= J <I）に到着したインオーダーパケットS [j]のように定義され、並べ替え不連続でパケットに関連付けられている[I ]。
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.
それは、3.4節で説明したように並べ替えシングルトンメトリックを用いて評価したときに[j]はここで、s> NextExp、シーケンスの不連続を引き起こすことがわかっているだろうよ注意してください。
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.
E =分（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).
並べ替えギャップが連続するリオーダリング不連続との間の距離です。タイプP-パケットギャップストリーム並べ替えメトリック「はストリーム内の（すべての）パケットに（（及びGapTimeの値（S [Jギャップ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が「]並び替え、パケットの到着に基づいて、リオーダリング不連続であることが見出された[I」]程度電子有する」、及び
an earlier reordering discontinuity s[j], based on the arrival of reordered packet s[i] with extent e was already detected, and
以前不連続S [j]を並べ替え、並べ替えられたパケットの到着に基づいて、[I]程度とEが既に検出された、そして
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:
以下に示すように、パケットのための並べ替えギャップ[J ']は、到着位置並び替え不連続との差です。
Gap(s[j']) = (j') - (j)
ギャップ（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 ']）（及びGapTime（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
タイプP-パケットの並べ替え - フリーラン-X-numrunsストリームタイプ-P-パケットの並べ替え - フリーラン-Q-squrunsストリームタイプ-P-パケットの並べ替え - フリーラン-P-numpkts-ストリーム型-P-パケット並べ替えフリーラン-accpktsストリーム
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
、インオーダーパケットのアキュムレータ+
+ 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 */ 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++;
}
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
平均並べ替えフリーラン長がある/ 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）/（/ X））に/ Qを比較することにより、平均から並べ替えフリーランの変化の指標を与えます。
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.
タイプP-パケットの並べ替え - フリーラン・ストリーム・パラメータは、平均的な並べ替えフリーラン長を含むストリームの並べ替え特性の概要、およびランレングスの変化を与えます。そのため、このメトリックの重要なアプリケーションは、ネットワークの評価です。
For 36 packets with 3 runs of 11 in-order packets, we have:
11で次のパケットの3回のランで36のパケットのために、私たちは持っています：
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。並べ替えフリーラン= 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:
3つのラン、長さ1の2つのラン、及び長さ31の1つと36個のパケットのために、我々は：
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。並べ替えフリーラン= 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）/（/ 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節に）並べ替えパケットの3例を区別するために楽器を持っているべきであることをお勧めします。上記で定義されたサンプルメトリックはわずかにまたは著しくアウトオブオーダーのパケットを分類するための要件を満たします。このセクションのメトリックは、並べ替えがDUP-ACKしきい値は高速再送アルゴリズムが呼び出される原因となっ超過されることがありますかどうかを推定する機能を追加します。追加のTCPカーネル・インスツルメンツは、[Mat03]にまとめられています。
Type-P-Packet-n-Reordering-Stream
タイプP-パケット-N-ストリーム並べ替え
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の間には関係がないことに注意してください。一方、損失がkより少ないL行うことができ、一方、重複がkよりも大きいLを作ることができる）がkに、各送信パケット1をシーケンス番号を割り当て、パケットの排出のためです。
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：受信したパケット番号i（nは<私は= Lを<）ソースシーケンス番号S [i]を用いて、n型並べ替えされた場合にのみ、その結果、すべてのjについてもし<= 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コードによって示されたコードは、1から（100に設定されたコードでMAXN）指定されたパラメータにnに対してn型並び替え決定およびレポート。 nの値は、TCPのために関連すると推測（[RFC 2581]のセクション3.2のパラグラフ2で3の値に設定されている）TCP重複ACK閾値です。
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型並べ替えでは、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は、試料中のN-並べ替えたパケットの数であるM / Lです。
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-並べ替えメトリックは、所与の経路に重複ACKしきい値の設定を一致させるために有用です。パスはせいぜい5並べ替えを示す場合、例えば、6のDUP-ACK閾値は不要再送信を回避することができます。
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の場合、NewRenoのTCP送信者は、3並べ替えのインスタンスに応じて、1つのパケットを再送し、したがって、輻輳制御の目的のために失われたこのパケットを検討する（送信側は、その輻輳ウィンドウを半分に表示されます[RFC2581]）。 TCPのような輻輳制御[RFC4341]：輻輳制御ID 2で使用した場合スリーストリーム制御転送プロトコル（SCTP）[RFC2960]、およびデータグラム輻輳制御プロトコル（DCCP）のデフォルトのしきい値[RFC4340]です。
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型並べ替え指定は、そのリオーダリング程度、Eに時々等しいです。 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.順序変更パケット（タイプP-順序変更= TRUE）E、N-並べ替えではないかもしれないが、広がりを持っているであろう（例を参照）。
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を使用するアプリケーションについての推論を行うためには、[RFC3148]のようにTCPのようなストリームを使用する必要があります
+ 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]をストリームを使用して、他のIPPM指標でセクション3と4のメトリックを報告するために許容可能です。ポアソンストリームはパケット損失および遅延メトリックのネットワークパフォーマンスの「公正なサンプル」を表します。しかし、ポアソンストリームを用いて測定し、並べ替えメトリックを使用して上記のアプリケーションカテゴリについての推論を行うために正しくないだろう。
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.順序変更パケットも補正係数の適切な適用のために検出されなければなりません。
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は、1つのパケットが並べ替えされ並べ替え、前記パケットが到着に応じて記載されているパケットの単純なケースを与え、メッセージ番号が使用されます。すべてのパケットは、SrcByte =（S×100）、S = 1,2,3,4のために-99と、PayloadSize = 100のバイトを含みます...
Table 1: Example with Packet 4 Reordered, Sending order( s @Src): 1,2,3,4,5,6,7,8,9,10
表1：パケット4順序変更と実施例、送信順序（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
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パケットのタイムスタンプ、ミリ秒。先のDstTimeパケットのタイムスタンプ、ミリ秒。パケットの遅延1ウェイ遅延、ミリ秒。 IPDV IPパケット遅延変動、パケットが目的地に到着したMS IPDV =遅延（SrcNum）-delay（SrcNum-1）DstOrderオーダー。バイトで、並べ替え、パケットのバイトオフセットをバイトオフセット。ミリ秒で、並べ替え、パケットの遅れを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-パケット並べ替えエクステント・ストリームの定義を適用します：
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以上である場合。 J = 5,6> 4ので、並べ替え範囲は3以上である場合。 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、しかし<4 3、及び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の到着に比べて遅い時間（DstTimeを使用して210から148 = 62ms）を計算することができます。受信機は、4つの以上のパケット、または少なくとも62ミリ秒の記憶を保持するデジッタバッファを有する場合、パケット4が有用であり得ます。パケット4は、少なくとも62ms早く到着した場合は1ウェイ遅延とIPDVは、また、パケット4の異常な動作を示していることに注意してください、それはこの例では、インオーダーされていると思います。
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
パケット5及び6と、表2の例は、オーダーを送信し、順序変更（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
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の両方が並べ替えられます。後期（= 1 189から188まで、190から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、我々は<5 4を有している場合、そう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、> 6 7ので、並べ替え範囲は、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を保持するために）必要とするが、E = 2パケット6のためのものです。
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.
それは（シングルトンメトリックと一致）1並べ替えされているので仮定のセンダ/レシーバのペアは、不必要にパケット5を再送信することができます。パケット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
パケット4、5、及び6と表3の例は、オーダーを送信並べ替え（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
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つのパケットが長い通過時間を有する場合、表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
ビン1 2 3 4 5 6 7周波数0 0 0 1 1 1 0
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、及び> 4~9ので、パケットは、2並べ替えされています。 N = 3,5 <= J <8、および> 4 8ので、パケットは、3並べ替えされています。 N = 4,4 <= J <8、および> 4 7ので、パケットは4並べ替えされています。場合はn = 5,3 <= J <8が、<4 3、及び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.
n = 1の場合、8 <= J <9が、4 <5ので、I = 9でパケットをn並べ替えとして指定されていない：パケット5 [9]次を考慮。私たちは、パケット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.2.3のテストを使用してパケット4と同じ並び替え不連続に関連付けられているかどうかを検討し、我々はすべての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リオーダリング定義は（DUP-ACK閾値= 3または4で）新しいリノTCPセンダずつ不要なパケット再送を引き起こす可能性のN-並べ替えの十分な程度を有する単一のパケット（4）を特定することを再び示しています。また、パケット5及び6の並べ替え到着は、受信処理、パケット5及び6のシングルトンタイプP-順序変更が= TRUE（プロトコルスタックアップ10を介してパケット7を通過できるようになり、それらは全て、単一の並べ替えに関連しています不連続）。
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
複数のパケット並べ替え不連続送信順序（S @Src）とともに表4実施例：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は、パケット5はエクステントE = 3であり、パケット11は、E = 2を有し、エクステントE = 2を有しています。二つの異なる並べ替え不連続、パケット6に1つ（ただし、j = 4）、パケット12（J '= 11）に1があります。
According to the definition of Reordering Gap Gap(s[j']) = (j') - (j) Gap(Packet 12) = (11) - (4) = 7
並べ替えギャップギャップ（S [J ']の定義によれば）=（J'） - （j）のギャップ（パケット12）=（11） - （4）= 7
We also have three reordering-free runs of lengths 5, 0, and 5.
また、長さ5、0、および5の3並べ替えフリーランを持っています。
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).
このメトリックは、介在するネットワークを介して別のホスト（宛先）への1つのホスト（ソース）から送信されたパケットのストリームを必要とします。この方法は、宛先および/または介在するネットワーク（複数可）に向け、サービス拒否攻撃に悪用される可能性があります。
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 in [RFC4656]. The security considerations sections of the two OWAMP documents are extensive and should be consulted for additional details.
このような抵抗を達成するため、悪意のある当事者とメカニズムによる干渉に対するデータ収集抵抗の要件は、他のIPPMメモに利用可能です。データ収集プロトコルのための要件のセットは、[RFC3763]に見出すことができ、ワンウェイアクティブな測定プロトコル（OWAMP）のためのプロトコル仕様は[RFC4656]です。 2つのOWAMPドキュメントのセキュリティの考慮事項のセクションでは、広範であり、その他の詳細のために相談する必要があります。
Metrics defined in this memo have been registered in the IANA IPPM METRICS REGISTRY as described in initial version of the registry [RFC4148].
レジストリ[RFC4148]の初期バージョンで説明したように、このメモで定義されたメトリックは、IANA IPPM METRICSレジストリに登録されています。
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 }
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 }
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 OBJECT-IDENTITYステータス現在の説明
"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 }
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 }
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 }
ietfReorderingFreeRuna OBJECT-IDENTITY STATUS current DESCRIPTION
ietfReorderingFreeRuna OBJECT-IDENTITYステータス現在の説明
"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 }
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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]マティス、M.およびM.オールマン、「実証バルク転送容量のメトリックを定義するためのフレームワーク」、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.モートン、 "定期的なストリームとのネットワークパフォーマンスの測定"、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]ステファン、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.、カープ、A.、BOOTE、J.、およびM. Zeckauskas、 "一方向アクティブな測定プロトコル（OWAMP）"、RFC 4656、2006年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.サヴェージ、ACM SIGCOMMインターネット測定ワークショップ2002年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.ベネット、C.パートリッジ、および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.モートン、 "アウトオブシーケンス（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.モートン、およびG.ラマチャンドラン、 "ティア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ら、「ティア1のIPバックボーンにおけるアウトオブシーケンスパケットの測定と分類、」ACM SIGCOMMインターネット計測ワークショップ2002年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.
[Lou01] D. LoguinovとH.ラダ、「低ビットレートのインターネットビデオストリーミングの測定研究」、ACM SIGCOMMインターネット測定ワークショップの議事録2001年11月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.マシス、J. Heffner、およびR.レディ "のWeb100：研究、教育および診断のための拡張TCP計装"、ACMコンピュータコミュニケーションレビュー、第33巻、テンキー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.パクソン、「測定およびエンドツーエンドのインターネットダイナミクスの分析、」博士論文、U.C.バークレー、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]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control ", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、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.、Kalidindi、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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]デミチェリス、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]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年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]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（DCCP）輻輳制御ID 2用のプロフィール：TCPのような輻輳制御"、RFC 4341、2006年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.挽歌、A.ベア、A. P. Jayasumana、 "パケットシーケンスで並べ替えの程度を指標"、PROC。ローカルコンピュータネットワーク、タンパ、FL、2002年11月に第27回IEEE会議。
[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].
著者はマットZekauskas、（並べ替えフリーランのセクションを執筆）ジョン・ベネット、そしてマット・マシスと多くの有用な議論を承認したいと思います。私たちは、IPPMリストで私たちと実装の経験を共有するためのデヴィッド・ニューマン、ヘンク・Uijterwaal、マーク・オールマン、バーン・パクソン、および彼らのレビューと提案のためのフィルChimento、およびミハルPrzybylskiの感謝します。 Anura JayasumanaとNischal Piratlaは、最近作業中の[TBABAJ02]をもたらしました。私たちは感謝IPパフォーマンスのフレームワーク[RFC2330]の著者によって敷設基盤を認めます。
Appendix A. Example Implementations in C (Informative)
C付録A.例の実装（参考情報）
Two example c-code implementations of reordering definitions follow:
並べ替え定義の2つの例示的なCコードの実装は、次のとおりです。
Example 1 n-reordering ============================================
#include <stdio.h>
書式#include <stdio.hに>
#define MAXN 100
#define MAXN 100
#define min(a, b) ((a) < (b)? (a): (b)) #define loop(x) ((x) >= 0? x: x + MAXN)
#define分（A、B）（（A）<（B）（A）：（B））の#defineループ（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.
*
*/
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;
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);
}
/* 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分（A、B）（（A）<（B）（A）：（B））の#defineループ（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)*/
/* 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;
}
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;
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は、フラグメント再構成が評価を注文する前に想定されると述べたが、同様の手順が前リアセンブリに適用することができること。この付録では、断片化を含むパケットストリームで並べ替え識別するための定義と手順を提供します。
B.1. Metric Name
B.1。メトリック名
The Metric retains the same name, Type-P-Reordered, but additional parameters are required.
メトリックは、Type-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 OSは逆の順序で断片を送ったので、この可能性はチェックする価値があります。
B.2. Additional Metric Parameters
B.2。追加のメトリックパラメータ
+ MoreFrag, the state of the More Fragments Flag in the IP header.
+ MoreFrag、IPヘッダ内の複数のフラグメントフラグの状態。
+ 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ヘッダのシーケンス番号と同じであると仮定されます。また、NextExpの値は、フラグメントのインオーダー到着と変わりません。最後のフラグメントまたは完全なパケットが到着したとき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.
行方不明の断片を持つパケットが失われたと宣言しなければならない、と到着しない任意の断片の並べ替え状態はサンプル指標から除外されなければならないことに注意してください。
B.3. Definition
B.3。定義
The value of Type-P-Reordered is typically false (the packet is in-order) when
タイプP-並べ替えられの値は、（パケットがインオーダーである）場合、典型的には偽であります
* the sequence number s >= NextExp, AND
*シーケンス番号S> = NextExp、AND
* the fragment offset FragOffset >= NextExpFrag
*フラグメントオフセットFragOffset> = NextExpFrag
However, it is more efficient to define reordered conditions exactly and designate Type-P-Reordered as False otherwise.
しかし、正確に並べ替え条件を定義し、それ以外の場合はタイプP-順序変更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.
タイプP-並べ替えられの値は、以下の条件で（パケットを再順序付けされる）真として定義されます。これらのケースでは、NextExp値は変更されません。
Case 1: if s < NextExp
ケース1：S <NextExp場合
Case 2: if s < FragSeq#
ケース2：Sの場合<FragSeq＃
Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag
ケース3：もしS> = NextExpとS = FragSeq＃と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;
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;
}
}
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.
コードの作業バージョンは、パケットのすべてのフラグメントは、サンプル・メトリックのように、さらなる順序変更ステータスを使用する前に到着することを保証するためのチェックを含むであろう。
B.4. Discussion: Notes on Sample Metrics When Evaluating Fragments
B.4。ディスカッション：フラグメントを評価するサンプル・メトリックの注意事項
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.
フラグメントオフセットは、単に心のオフセットの8つのオクテット単位を保ち、（= 0フラグメントオフセットを有する）最初のパケットのSourceByteに追加された場合、バイトストリームの番号と評価を簡略化することができます。
Appendix C. Disclaimer and License
付録C.免責事項とライセンス
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
アルモートンAT＆T LabsのルームD3 - 3C06 200ローレルアベニュー。南ミドルタウン、NJ 07748 USA電話+1 732 420 1571 Eメール：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
レンCiavattone AT＆T LabsのルームA2 - 4G06 200ローレルアベニュー。南ミドルタウン、NJ 07748 USA電話+1 732 420 1239 Eメール：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ラマチャンドランAT＆T LabsのルームC4 - 3D22 200ローレルアベニュー。南ミドルタウン、NJ 07748 USA電話+1 732 420 2353 Eメール：gomathi@att.com
Stanislav Shalunov Internet2 1000 Oakbrook DR STE 300 Ann Arbor, MI 48104 Phone: +1 734 995 7060 EMail: shalunov@internet2.edu
スタニスラフ・シャルノブインターネット2千オークブルックDR STE 300アナーバー、MI 48104電話：+1 734 995 7060 Eメール：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
ジェリーPerser Veriwave 8770 SWニンバスアベニュー。スイートBビーバートン、OR 97008 USA電話：+1 818 338 4112 Eメール：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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。