[要約] RFC 4737は、パケットの再順序化メトリクスに関する情報を提供するものであり、ネットワークのパフォーマンス評価やトラブルシューティングに役立ちます。目的は、再順序化の度合いを測定し、ネットワークの品質を向上させることです。
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).
Copyright（c）The IETF Trust（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:
以下の定義は、次の目標を満たすつもりです。
1. Determining whether or not packet reordering has occurred.
1. パケットの並べ替えが発生したかどうかを判断します。
2. Quantifying the degree of reordering. (We define a number of metrics to meet this goal, because receiving procedures differ by protocol or application. Since the effects of packet reordering vary with these procedures, a metric that quantifies a key aspect of one receiver's behavior could be irrelevant to 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. ソースと目的地の輸送アドレス、および異なるパケットトリートメントをもたらす可能性のあるその他の情報を含む、パケットストリームの「Type-Pのパケット」[RFC2330]識別子。
2. The stream parameter set for the sending discipline, such as the parameters unique to periodic streams (as in [RFC3432]), TCP-like streams (as in [RFC3148]), or Poisson streams (as in [RFC2330]). The stream parameters include the packet size, specified either as a fixed value or as a pattern of sizes (as applicable).
2. 周期的なストリーム（[RFC3432]のように）に固有のパラメーター、TCP様ストリーム（[RFC3148]のように）、またはポアソンストリーム（[RFC2330]のように）など、送信規律に設定されたストリームパラメーター。ストリームパラメーターには、固定値として、またはサイズのパターン（該当する場合）として指定されたパケットサイズが含まれます。
Whenever a metric is reported, it MUST include a description of these parameters to provide a context for the results.
メトリックが報告されるたびに、結果のコンテキストを提供するために、これらのパラメーターの説明を含める必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different implementations are comparable, and to note instances when an implementation could perturb the network.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。RFC 2119はプロトコルを念頭に置いて書かれていますが、キーワードは同様の理由でこのドキュメントで使用されています。これらは、2つの異なる実装からの測定結果が同等であることを確認し、実装がネットワークを摂動できる場合に注意するために使用されます。
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.
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.)
2番目のサポートコンセプトは、「次の予想」パケット番号である保存値です。通常の条件下では、次の予想（nextExp）の値は、メッセージ番号の前のパケットと1のシーケンス番号です。（一般に、受信者は、「次の予想」を決定できるように、送信者のアルゴリズムと識別子のシーケンスを再現します。）
Each packet within a packet stream can be evaluated with this order singleton metric.
パケットストリーム内の各パケットは、この注文シングルトンメトリックで評価できます。
Type-P-Reordered
タイプ-Preorded
+ 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.
+ IS、ソース、メッセージの単位に適用される一意のパケットシーケンス番号です。
+ 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.
+ ペイロードサイズ、情報フィールドに含まれるバイト数で、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値と比較して並べ替えられることがわかった場合、その型preorded = true;それ以下で定義するように、type-p-reordered = false：
The value of Type-P-Reordered is defined as TRUE if s < NextExp (the packet is reordered). In this case, the NextExp value does not change.
型preordedの値は、s <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.
型preordedの値は、s> = nextexp（パケットは次数です）の場合、falseとして定義されます。この場合、nextExpはs 1に設定されており、次のパケットと比較して到着します。
Since the NextExp value cannot decrease, it provides a non-reversing order criterion to identify reordered packets.
NextExp値は減少できないため、並べ替えられたパケットを識別するための非反転順序基準を提供します。
This definition can also be specified in pseudo-code.
この定義は、擬似コードでも指定できます。
On successful arrival of a packet with sequence number s:
シーケンス番号sを備えたパケットの到着が成功したとき：
if s >= NextExp then /* s is in-order */
NextExp = s + 1;
Type-P-Reordered = False;
else /* when s < NextExp */
Type-P-Reordered = True
Packets with s > NextExp are a special case of in-order delivery. This condition indicates a sequence discontinuity, because of either packet loss or reordering. Reordered packets must arrive for the sequence discontinuity to be defined as a reordering discontinuity (see Section 4).
s> nextexpを備えたパケットは、次の配信の特別なケースです。この条件は、パケットの損失または再注文のいずれかのため、シーケンスの不連続性を示します。並べ替えられたパケットは、シーケンスの不連続性を並べ替えて、再注文の不連続として定義する必要があります（セクション4を参照）。
We define two different states for in-order packets.
When s = NextExp, the original sequence has been maintained, and there is no discontinuity present.
S = nextExpの場合、元のシーケンスが維持されており、不連続性はありません。
When s > NextExp, some packets in the original sequence have not yet arrived, and there is a sequence discontinuity associated with packet s. The size of the discontinuity is s - NextExp, equal to the number of packets presently missing, either reordered or lost.
s> nextexpの場合、元のシーケンスの一部のパケットはまだ到着しておらず、パケットに関連するシーケンスの不連続性があります。不連続性のサイズはs- nextexpで、現在欠落しているパケットの数に等しく、並べ替えまたは紛失します。
In pseudo-code:
擬似コードで：
On successful arrival of a packet with sequence number s:
シーケンス番号sを備えたパケットの到着が成功したとき：
if s >= NextExp, then /* s is in-order */
if s > NextExp then
SequenceDiscontinuty = True;
SeqDiscontinutySize = s - NextExp;
else
SequenceDiscontinuty = False;
NextExp = s + 1;
Type-P-Reordered = False;
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.
SRCTIMEとSRCBYTEがユニークで信頼性が高い限り、セクション3.3の定義で並べ替えをテストするために、時間またはペイロードバイトの代替寸法を使用して使用することができます。シーケンスの不連続性は、メッセージの番号付けで簡単に定義および検出されます。ただし、これは時間やバイトの次元ではそれほど単純ではありません。これは、シーケンスの不連続定義がサンプルメトリックで重要な役割を果たしているため、代替次元の批判者です。
It is possible to detect sequence discontinuities with payload byte numbering, but only when the test device knows exactly what value to assign as NextExp in response to any packet arrival. This is possible when the complete pattern of payload sizes is stored at the destination, or if the size pattern can be generated using a pseudo-random number generator and a shared seed. If payload size is constant, byte numbering adds needless complexity over message numbering.
ペイロードバイト番号付けでシーケンスの不連続性を検出することは可能ですが、テストデバイスがパケットの到着に応じてnextExpとして割り当てる値を正確に把握している場合のみです。これは、ペイロードサイズの完全なパターンが目的地に保存されている場合、または擬似ランダム数ジェネレーターと共有シードを使用してサイズパターンを生成できる場合に可能です。ペイロードサイズが一定の場合、バイト番号はメッセージ番号よりも不必要な複雑さを追加します。
It may be possible to detect sequence discontinuities with periodic streams and source time numbering, but there are practical pitfalls with sending exactly on-schedule and with clock reliability.
定期的なストリームとソース時間番号を使用して、シーケンスの不連続性を検出することが可能かもしれませんが、スケジュール上および時計の信頼性を正確に送信することには実際的な落とし穴があります。
The dimensions of time and bytes remain an important basis for characterizing the extent of reordering, as described in Sections 4.3 and 4.4.
セクション4.3および4.4で説明されているように、時間とバイトの寸法は、並べ替えの程度を特徴付けるための重要な基盤のままです。
Any arriving packet bearing a sequence number from the sequence that establishes the NextExp value can be evaluated to determine whether it is in-order or reordered, based on a previous packet's arrival. In the case where NextExp is Undefined (because the arriving packet is the first successful transfer), the packet is designated in-order (Type-P-Reordered=FALSE).
nextExp値を確立するシーケンスのシーケンス番号を持つ到着パケットを評価して、以前のパケットの到着に基づいて、それが順序であるか、再注文されているかを判断できます。nextExpが未定義の場合（到着するパケットが最初の成功した転送であるため）、パケットは次数（type-p-reordered = false）に指定されます。
This metric assumes reassembly of packet fragments before evaluation. In principle, it is possible to use the Type-P-Reordered metric to evaluate reordering among packet fragments, but each fragment must contain source sequence information. See Appendix B, "Fragment Order Evaluation", for more detail.
このメトリックは、評価前にパケットフラグメントの再組み立てを想定しています。原則として、タイプ-Preordedメトリックを使用してパケットフラグメント間の並べ替えを評価することができますが、各フラグメントにはソースシーケンス情報を含める必要があります。詳細については、付録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
タイプ-Preorded-ratio-stream
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:
パラメーターセットには、タイプ-Preordedのシングルトンパラメーターが含まれています。ポアソンストリームに固有のパラメーター（[RFC2330]のように）、周期的なストリーム（[RFC3432]のように）、またはTCP様ストリーム（[RFC3148]のように）;パケットサイズまたはサイズパターン。そして次の：
+ T0, a start time
+ T0、開始時間
+ Tf, an end time
+ TF、終了時間
+ dT, a waiting time for each packet to arrive, in seconds
+ DT、各パケットが到着するのが秒単位で待ち時間
+ K, the total number of packets in the stream sent from source to destination
+ K、ソースから宛先に送信されるストリーム内のパケットの総数
+ L, the total number of packets received (arriving between T0 and Tf+dT) out of the K packets sent. Recall that identical copies (duplicates) have been removed, so L <= K.
+ 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."
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 )
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.
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).
各パケットには、パケット送信の順に1からkまでの連続した整数（ソース）が割り当てられています。
Let s[1], s[2], ..., s[L] represent the original sequence numbers associated with the packets in order of arrival.
s [1]、s [2]、...、s [l]は、到着順にパケットに関連付けられた元のシーケンス番号を表します。
s[i] can be thought of as a vector, where the index i is the arrival position of the packet with sequence number s. In theory, any source sequence number could appear in any arrival position, but this is unlikely in reality.
s [i]は、インデックスIがシーケンス番号sのパケットの到着位置であるベクトルと考えることができます。理論的には、任意のソースシーケンス番号は任意の到着位置に表示される可能性がありますが、これは実際にはありそうにありません。
Consider a reordered packet (Type-P-Reordered=TRUE) with arrival index i and source sequence number s[i]. There exists a set of indexes j (1 <= j < i) such that s[j] > s[i].
到着インデックスIおよびソースシーケンス番号s [i]を使用した並べ替えられたパケット（type-p-reordered = true）を考えてみましょう。s [j]> s [i]のインデックスj（1 <= j <i）のセットが存在します。
The new parameters are:
新しいパラメーターは次のとおりです。
+ i, the index for arrival position, where i-1 represents an arrival earlier than i.
+ I、到着位置のインデックスで、I-1はiよりも早く到着を表します。
+ j, a set of one or more arrival indexes, where 1 <= j < i.
+ J、1つ以上の到着インデックスのセット、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.
+
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]の並べ替えの範囲は、s [j]> s [i]の最小値に対してi-nと定義されます。
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.
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:
タイプ-Preordered-ratio-streamに定義されたパラメーターに加えて、次のように指定します。
+ DstTime, the time that each packet in the stream arrives at the destination, and may be associated with index i, or packet s[i]
+ 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:
時間の遅れは、宛先時間を使用して計算されます。受信した場合、パケットは並べ替えられ、並べ替えの範囲があります。
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].
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:
並べ替えられたパケットのバイトストリームオフセット[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はs [i]より大きくなります。
Packets that meet both these criteria are normally buffered until the sequence beneath them is complete. Note that these criteria apply to both in-order and reordered packets.
これらの両方の基準を満たすパケットは、通常、その下のシーケンスが完了するまでバッファリングされます。これらの基準は、注文および並べ替えられたパケットの両方に適用されることに注意してください。
For reordered packet s[i] with a reordering extent e:
並べ替えの範囲を並べ替えたパケットの場合e：
ByteOffset(s[i]) = Sum[qualified packets]
= Sum[PayloadSize(packet at i-1 if qualified),
PayloadSize(packet at i-2 if qualified), ...
PayloadSize(packet at i-e always qualified)]
Using our earlier notation:
以前の表記を使用してください：
ByteOffset(s[i]) =
Sum[payloads of s[j] where s[j]>s[i] and i > j >= i-e]
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パケットバイバイトオフセットストリームメトリックを使用して、保存されたパケットのペイロードサイズの点でオフセットを特徴付けることが最も便利かもしれません。
The byte offset metric can help predict whether reordered packets will be useful in a general receiver buffer system with finite limits. The limit is expressed as the number of bytes the buffer can store.
バイトオフセットメトリックは、並べ替えられたパケットが有限制限のある一般的なレシーバーバッファシステムで役立つかどうかを予測するのに役立ちます。制限は、バッファーが保存できるバイト数として表されます。
A sample's ByteOffset results may be expressed as a histogram to summarize the frequency of buffer lengths needed to accommodate reordered packets and permit buffer tuning on that basis. A CDF with buffer size vs. percent of reordered packets accommodated may be informative.
サンプルのバイトオフセット結果は、並べ替えられたパケットに対応し、その基準でバッファチューニングを許可するために必要なバッファー長の頻度を要約するヒストグラムとして表される場合があります。バッファサイズのCDF対並べ替えられたパケットのパーセントは、有益な場合があります。
Type-P-Packet-Reordering-Gap-Stream Type-P-Packet-Reordering-GapTime-Stream
タイプ-P-パケット - ロードリングギャップ - ストリームタイプ-P-パケット - ロードリング-Gaptime-Stream
We use the same parameters defined earlier, but add the convention that index i' is greater than i, likewise j' > j, and define:
以前に定義されたのと同じパラメーターを使用しますが、インデックスI 'が私よりも大きいという規則を追加します。
+ Gap(s[j']), the Reordering Gap of packet s[j'] in units of integer messages
+ gap（s [j ']）、整数メッセージの単位におけるパケットs [j']の並べ替えギャップ
and the OPTIONAL parameter:
およびオプションのパラメーター：
+ GapTime(s[j']), the Reordering Gap of packet s[j'] in units of seconds
+ gaptime（s [j ']）、秒単位のパケットs [j']の並べ替えギャップ
All reordered packets are associated with a packet at a reordering discontinuity, defined as the in-order packet s[j] that arrived at the minimum value of j (1<=j<i) for which s[j]> s[i].
すべての並べ替えられたパケットは、s [j]> s [iのj（1 <= j <i）の最小値に到達した順序パケットs [j]として定義される、再注文の不連続性のパケットに関連付けられています。]。
Note that s[j] will have been found to cause a sequence discontinuity, where s > NextExp when evaluated with the reordered singleton metric as described in Section 3.4.
S [j]は、セクション3.4で説明されているように、並べ替えられたシングルトンメトリックで評価された場合、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.
i -e = min（j）を思い出してください。後続の並べ替えられたパケットは、同じs [j]、または異なる不連続に関連付けられている場合があります。この事実は、以下の並べ替えギャップの定義で使用されます。
A reordering gap is the distance between successive reordering discontinuities. The Type-P-Packet-Reordering-Gap-Stream metric assigns a value for Gap(s[j']) to (all) packets in a stream (and a value for GapTime(s[j']), when reported).
並べ替えるギャップは、連続した並べ替えの不連続性の間の距離です。Type-P-Packet-Reordering-Gap-Stream Metricは、報告時にGAP（S [J ']）に（およびGaptimeの値（S [J']）の値（およびgaptime（s [j ']））に値を割り当てます）。
If:
もしも：
the packet s[j'] is found to be a reordering discontinuity, based on the arrival of reordered packet s[i'] with extent e', and
パケットs [j ']は、再注文パケットs [i']の到着に基づいて、e程度のe 'を並べることに基づいて、並べ替えの不連続性であることがわかりました。
an earlier reordering discontinuity s[j], based on the arrival of reordered packet s[i] with extent e was already detected, and
再秩序化されたパケットの到着に基づいた以前の並べ替えの不連続性がすでに検出されており、
i' > i, and
I '> i、および
there are no reordering discontinuities between j and j',
JとJ 'の間に不連続性を並べ替えることはありません。
then the Reordering Gap for packet s[j'] is the difference between the arrival positions the reordering discontinuities, as shown below:
次に、パケットs [j ']の並べ替えギャップは、以下に示すように、到着不連続性の違いの違いです。
Gap(s[j']) = (j') - (j)
Gaps MAY also be expressed in time:
ギャップは時間内に表現される場合があります。
GapTime(s[j']) = DstTime(j') - DstTime(j)
Otherwise:
さもないと：
Gap(s[j']) (and GapTime(s[j']) ) for packet s[j'] is 0.
gap（s [j ']）（およびgaptime（s [j']））for packet s [j ']は0です。
When separate reordering discontinuities can be distinguished, a count may also be reported (along with the discontinuity description, such as the number of reordered packets associated with that discontinuity and their extents and offsets). The Gaps between a sample's reordering discontinuities may be expressed as a histogram to easily summarize the frequency of various gaps. Reporting the mode, average, range, etc., may also summarize the distributions.
別々の再注文不連続性を区別できる場合、カウントも報告される場合があります（その不連続に関連する再注文パケットの数とその範囲とオフセットの数などの不連続の説明とともに）。サンプルの並べ替えの不連続性の間のギャップは、さまざまなギャップの頻度を簡単に要約するためのヒストグラムとして表される場合があります。モード、平均、範囲などを報告することも、分布を要約する場合があります。
The Gap metric may help to correlate the frequency of reordering discontinuities with their cause. Gap lengths are also informative to receiver designers, revealing the period of reordering discontinuities. The combination of reordering gaps and extent reveals whether receivers will be required to handle cases of overlapping reordered packets.
This section defines a metric based on a count of consecutive in-order packets between reordered packets.
Type-P-Packet-Reordering-Free-Run-x-numruns-Stream Type-P-Packet-Reordering-Free-Run-q-squruns-Stream Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream
Type-P-Packet-Reorder-free-run-x-numruns-stream type-p-packet-reorder-free-run-q-squruns-stream-p-packet-reording-reording-run-p-numpkts-Stream Type-P-Packet-Reorder-Free-Run-A-ACCPKTS-STREAM
We use the same parameters defined earlier and define the following:
以前に定義された同じパラメーターを使用し、以下を定義します。
+ r, the run counter
+ R、ランカウンター
+ x, the number of runs, also the number of reordered packets
+ X、実行数、また並べ替えられたパケットの数
+ a, the accumulator of in-order packets
+ A、注文パケットのアキュムレータ
+ p, the number of packets (when the stream is complete, p=(x+a)=L)
+ P、パケットの数（ストリームが完了したとき、p =（x a）= l）
+ q, the sum of the squares of the runs counted
+ Q、カウントされたランの正方形の合計
As packets in a sample arrive at the destination, the count of in-order packets between reordered packets is a Reordering-Free run. Note that the minimum run-length is zero according to this definition. A pseudo-code example follows:
サンプル内のパケットが目的地に到着すると、並べ替えられたパケット間の注文パケットの数は、並べ替えのない実行です。この定義によると、最小走行長はゼロであることに注意してください。擬似コードの例は次のとおりです。
r = 0; /* r is the run counter */
x = 0; /* x is the number of runs */
a = 0; /* a is the accumulator of in-order packets */
p = 0; /* p is the number of packets */
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
平均並べ替えフリーの実行長はA/xです
The q counter gives an indication of variation of the Reordering-Free runs from the average by comparing q/a to a/x ((q/a)/(a/x)).
Qカウンターは、Q/AをA/X（（Q/A）/（A/X））と比較することにより、平均からの並べ替えのない実行の変動の指標を示します。
Type-P-packet-Reordering-Free-Run-Stream parameters give a brief summary of the stream's reordering characteristics including the average reordering-free run length, and the variation of run lengths; therefore, a key application of this metric is network evaluation.
For 36 packets with 3 runs of 11 in-order packets, we have:
11個の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
For 36 packets with 3 runs, 2 runs of length 1, and one of length 31, we have:
3回のラン、2回の長さ1、および長さ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
The variability in run length is prominent in the difference between the q values (sum of the squared run lengths) and in comparing average run length to the (q/a)/(a/x) ratios (equals 1 when all runs are the same length).
実行長の変動性は、q値（四角の実行長の合計）と平均実行長を（q/a）/（a/x）比と比較することで顕著です（すべての実行がすべてのランがある場合に1に等しい同じ長さ）。
This section describes a metric that conveys information associated with the effect of reordering on TCP. However, in order to infer anything about TCP performance, the test stream MUST bear a close resemblance to the TCP sender of interest. [RFC3148] lists the specific aspects of congestion control algorithms that must be specified. Further, RFC 3148 recommends that Bulk Transfer Capacity metrics SHOULD have instruments to distinguish three cases of packet reordering (in Section 3.3). The sample metrics defined above satisfy the requirements to classify packets that are slightly or grossly out-of-order. The metric in this section adds the capability to estimate whether reordering might cause the DUP-ACK threshold to be exceeded causing the Fast Retransmit algorithm to be invoked. Additional TCP Kernel Instruments are summarized in [Mat03].
このセクションでは、TCPに対する並べ替えの効果に関連する情報を伝えるメトリックについて説明します。ただし、TCPのパフォーマンスに関するものを推測するためには、テストストリームは、関心のあるTCP送信者と密接に似ている必要があります。[RFC3148]は、指定する必要がある輻輳制御アルゴリズムの特定の側面をリストします。さらに、RFC 3148は、バルク転送容量メトリックには、パケットの並べ替えの3つのケースを区別するための機器を備えていることを推奨しています（セクション3.3）。上記のサンプルメトリックは、わずかにまたは総秩序外のパケットを分類するための要件を満たしています。このセクションのメトリックでは、並べ替えがDUP-ackしきい値を超えている可能性があるかどうかを推定する機能を追加して、高速再送信アルゴリズムを呼び起こします。追加のTCPカーネル機器は[MAT03]にまとめられています。
Type-P-Packet-n-Reordering-Stream
Type-P-Packet-N-Reordering-Stream
Let n be a positive integer (a parameter). Let k be a positive integer equal to the number of packets sent (sample size). Let l be a non-negative integer representing the number of packets that were received out of the k packets sent. (Note that there is no relationship between k and l: on one hand, losses can make l less than k; on the other hand, duplicates can make l greater than k.) Assign each sent packet a sequence number, 1 to k, in order of packet emission.
nを正の整数（パラメーター）とします。Kを、送信されるパケットの数（サンプルサイズ）に等しい正の整数とします。Lを、送信されたKパケットから受信したパケットの数を表す非陰性整数とします。（KとLの間に関係がないことに注意してください。一方では、損失はlをkよりも少なくする可能性があります。他方では、複製はkよりもLを大きくすることができます。）パケット排出の順に。
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 <i <= l）は、ソースシーケンス番号s [i]で、すべてのjがi-n <= j <i、s [j]>である場合にのみn rederedです。S [i]。
Claim: If, by this definition, a packet is n-reordered and 0 < n' < n, then the packet is also n'-reordered.
クレーム：この定義により、パケットがn-reorderedと0 <n '<nがn'-reorderedになっている場合。
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]).
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.)
この定義は、特に連続したパケットのブロックが再注文されたときに、Singleton Metricで定義されているすべての並べ替えられたパケットにNを割り当てません。（到着シーケンスS = {1,2,3,7,8,9,4,5,6}、パケット4、5、および6は再注文されますが、パケット4のみがn留められ、n = 3で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 re順の程度はm/lで、mはサンプル内のn reorderedパケットの数です。
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.
The degree of n-reordering may be expressed as a percentage, in which case the number from Definition 2 is multiplied by 100.
N re順の程度はパーセンテージとして表される場合があります。この場合、定義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 rederingメトリックは、重複した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]を参照）。3つは、ストリーム制御トランスポートプロトコル（SCTP）[RFC2960]のデフォルトのしきい値、およびDatagramうっ血コントロールプロトコル（DCCP）[RFC4340]のデフォルトのしきい値：渋滞制御ID 2：TCP様うっ血制御[RFC4341]で使用する場合。
A sample's n-reordering may be expressed as a histogram to summarize the frequency for each value of n.
サンプルのn rederingは、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 rederingの定義は、密接に並べ替えられたシングルトンの場合など、一部の状況では、TCP送信者によって不必要に再送信されたパケットの正確な数を予測できないことに注意してください。時間と位置の両方が送信者の動作に影響します。
A packet's n-reordering designation is sometimes equal to its reordering extent, e. n-reordering is different in the following ways:
パケットのn redering指定は、その並べ替えの範囲に等しい場合があります。N-Reorderingは次の方法で異なります。
1. n is a count of early packets with consecutive arrival positions at the receiver.
1. nは、レシーバーに連続した到着位置を持つ初期パケットのカウントです。
2. Reordered packets (Type-P-Reordered=TRUE) may not be n-reordered, but will have an extent, e (see the examples).
2. 並べ替えられたパケット（type-p-reordered = true）はn-reordedではない場合がありますが、e（例を参照）があります。
The results of tests will be dependent on the time interval between measurement packets (both at the source, and during transport where spacing may change). Clearly, packets launched infrequently (e.g., 1 per 10 seconds) are unlikely to be reordered.
テストの結果は、測定パケット間の時間間隔（ソースの両方と、間隔が変化する可能性のある輸送中）に依存します。明らかに、発売されたパケットは、まれに（たとえば、10秒あたり1秒）並べ替えられる可能性は低いです。
In order to gauge the reordering for an application according to the metrics defined in this memo, it is RECOMMENDED to use the same sending pattern as the application of interest. In any case, the exact method of packet generation MUST be reported with the measurement results, including all stream parameters.
このメモで定義されているメトリックに従ってアプリケーションの並べ替えを測定するには、関心のあるアプリケーションと同じ送信パターンを使用することをお勧めします。いずれにせよ、すべてのストリームパラメーターを含む測定結果でパケット生成の正確な方法を報告する必要があります。
+ To make inferences about applications that use TCP, it is REQUIRED to use TCP-like Streams as in [RFC3148]
+ TCPを使用するアプリケーションについて推論するには、[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.
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.
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 rederingの並べ替えの程度または程度をウィンドウの長さよりも大きいと表現する必要があります。
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パケットの送信時間がネットワークの最大の転送時間に関して小さい場合にのみ、サンプルの数パケットに近づきます。ストレージのもう1つの可能な制限は、ほとんどのテストストリームが実際にこの長さを使い果たしていないと仮定して、シーケンス番号フィールドの最大長です。
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つのパケットが再注文され、パケット4が到着に応じてリストされ、メッセージ番号が使用されている、並べ替えの単純なケースを示します。すべてのパケットには、srcbyte =（s x 100）-99がs = 1,2,3,4、...でペイロードサイズ= 100バイトが含まれています。
Table 1: Example with Packet 4 Reordered,
Sending order( s @Src): 1,2,3,4,5,6,7,8,9,10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
5 4 80 148 68 -82 4
6 6 100 168 68 0 5
7 7 120 188 68 0 6
8 8 140 208 68 0 7
4 9 60 210 150 82 8 400 62
9 9 160 228 68 0 9
10 10 180 248 68 0 10
Each column gives the following information:
各列は次の情報を提供します。
s Packet sequence number at the source. NextExp The value of NextExp when the packet arrived (before update). SrcTime Packet time stamp at the source, ms. DstTime Packet time stamp at the destination, ms. Delay 1-way delay of the packet, ms. IPDV IP Packet Delay Variation, ms IPDV = Delay(SrcNum)-Delay(SrcNum-1) DstOrder Order in which the packet arrived at the destination. Byte Offset The byte offset of a reordered packet, in bytes. LateTime The lateness of a reordered packet, in ms.
ソースのSパケットシーケンス番号。nextExpパケットが到着したときのnextexpの値（更新前）。SRCTIMEパケットタイムスタンプソース、MS。DSTTIMEパケットタイムスタンプ、MS。パケットの遅延遅延、MS。IPDV IPパケット遅延バリエーション、MS IPDV = Delay（SRCNUM）-DELAY（SRCNUM-1）DSTORDER順序で、パケットが目的地に到着しました。バイトオフセットバイト単位の再注文パケットのバイトオフセット。MSで、並べ替えられたパケットの遅刻が遅れます。
We can see that when Packet 4 arrives, NextExp=9, and it is declared reordered. We compute the extent of reordering as follows:
Packet 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、しかし3 <4と4が最大範囲である場合、E = 4（この例のように、以前のシーケンスの不連続性がないと仮定します）。
Further, we can compute the Late Time (210-148=62ms using DstTime) compared to Packet 5's arrival. If the receiver has a de-jitter buffer that holds more than 4 packets, or at least 62 ms storage, Packet 4 may be useful. Note that 1-way delay and IPDV indicate unusual behavior for Packet 4. Also, if Packet 4 had arrived at least 62ms earlier, it would have been in-order in this example.
さらに、パケット5の到着と比較して、遅い時間（DSTTimeを使用して210-148 = 62ms）を計算できます。レシーバーに、4つ以上のパケットを保持するジッターバッファー、または少なくとも62ミリ秒のストレージを持っている場合、パケット4が役立つ場合があります。1方向の遅延とIPDVは、パケット4の異常な動作を示していることに注意してください。また、パケット4が少なくとも62ms前に到着した場合、この例では次の順序でした。
If all packets contained 100 byte payloads, then Byte Offset is equal to 400 bytes.
すべてのパケットに100バイトのペイロードが含まれている場合、バイトオフセットは400バイトに等しくなります。
Following the definitions of Section 5.1, Packet 4 is designated 4-reordered.
セクション5.1の定義に従って、パケット4は4項に指定されています。
Table 2 Example with Packets 5 and 6 Reordered, Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10
表2パケット5および6の例を並べ替え、送信注文（s @SRC）：1,2,3,4,5,6,7,8,9,10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
4 4 60 128 68 0 4
7 5 120 188 68 -22 5
5 8 80 189 109 41 6 100 1
6 8 100 190 90 -19 7 100 2
8 8 140 208 68 0 8
9 9 160 228 68 0 9
10 10 180 248 68 0 10
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.
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
/\ /\
Considering Packet 5 first:
パケット5を考慮してください：最初：
when j=5, 7 > 5, so the reordering extent is 1 or more. when j=4, we have 4 < 5, so 1 is its maximum extent, and e=1.
J = 5、7> 5の場合、並べ替えの範囲は1以上です。j = 4の場合、4 <5があるため、1は最大範囲、e = 1です。
Considering Packet 6 next:
パケット6を考慮してください。
when j=6, 5 < 6, the extent is not yet defined. when j=5, 7 > 6, so the reordering extent is i-j=2 or more. when j=4, 4 < 6, and we find 2 is its maximum extent, and e=2.
j = 6、5 <6の場合、範囲はまだ定義されていません。j = 5、7> 6の場合、並べ替えの範囲はi-j = 2以上です。j = 4、4 <6の場合、2が最大範囲であり、e = 2であることがわかります。
We can also associate each of these reordered packets with a reordering discontinuity. We find the minimum j=5 (for both packets) according to Section 4.2.3. So Packet 6 is associated with the same reordering discontinuity as Packet 5, the Reordering Discontinuity at Packet 7.
また、これらの並べ替えられた各パケットを再注文の不連続性に関連付けることもできます。セクション4.2.3によると、最小j = 5（両方のパケットの場合）が見つかります。したがって、パケット6は、パケット5と同じ並べ替えの不連続性に関連付けられています。
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.
これは、範囲を並べ替えて、注文を復元するために必要なパケットストレージを過大評価する場合です。必要なパケットストレージは1つだけです（パケット7を保持するため）が、パケット6の場合はE = 2です。
Following the definitions of Section 5, Packet 5 is designated 1-reordered, but Packet 6 is not designated n-reordered.
セクション5の定義に従って、パケット5は1項に指定されていますが、パケット6はN-Reorderedとは指定されていません。
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件の（Singleton Metricと一致して）1件の（Singleton Metricと一致）、パケット5を不必要に再送信する場合があります。パケット6は不必要に再送信されない場合がありますが、受信者はパケット6が到着するまでパケット7を高レイヤーに進めることはできません。したがって、Singleton Metricは、パケット6が再注文されることを正しく決定しました。
Table 3 Example with Packets 4, 5, and 6 reordered Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10,11
表3パケット4、5、および6の例を備えた例を並べ替えた送信注文（s @SRC）：1,2,3,4,5,6,7,8,9,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 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 rederingを計算します。パケット4を考慮してください：最初：
when n=1, 7<=j<8, and 10> 4, so the packet is 1-reordered. when n=2, 6<=j<8, and 9 > 4, so the packet is 2-reordered. when n=3, 5<=j<8, and 8 > 4, so the packet is 3-reordered. when n=4, 4<=j<8, and 7 > 4, so the packet is 4-reordered. when n=5, 3<=j<8, but 3 < 4, and 4 is the maximum n-reordering.
n = 1、7 <= j <8、および10> 4の場合、パケットは1項になっています。n = 2、6 <= j <8、および9> 4の場合、パケットは2項になります。n = 3、5 <= j <8、および8> 4の場合、パケットは3項になります。n = 4、4 <= j <8、および7> 4の場合、パケットは4項になります。n = 5、3 <= j <8、しかし3 <4、および4が最大n re順です。
Considering packet 5[9] next: when n=1, 8<=j<9, but 4 < 5, so the packet at i=9 is not designated as n-reordered. We find the same result for Packet 6.
パケット5 [9]を考慮してください次：n = 1、8 <= j <9、しかし4 <5の場合、i = 9のパケットはn reordedとして指定されていません。パケット6についても同じ結果が見つかります。
We now consider whether reordered Packets 5 and 6 are associated with the same reordering discontinuity as Packet 4. Using the test of Section 4.2.3, we find that the minimum j=4 for all three packets. They are all associated with the reordering discontinuity at Packet 7.
ここで、並べ替えられたパケット5と6がパケット4と同じ再注文の不連続性に関連付けられているかどうかを検討します。セクション4.2.3のテストを使用して、3つのパケットすべてで最小j = 4が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 rederingの定義が、新しいReno TCP送信者による1つの不必要なパケット再送信を引き起こす可能性のある十分なn re順で単一のパケット（4）を識別することを再度示しています（Dup-ackしきい値= 3または4）。また、パケット5と6の並べ替えられた到着により、受信機プロセスはパケット7〜10をプロトコルスタックに渡すことができます（シングルトンタイプ-P-ロード=パケット5および6にはTRUEであり、それらはすべて単一の並べ替えに関連付けられています。不連続）。
Table 4 Example with Multiple Packet Reordering Discontinuities Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
表4複数のパケットを並べ替える不連続性の並べ替え注文の送信（s @SRC）：1,2,3,4,5,6,7,8,9,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.)
Packet 4 has extent e=2, Packet 5 has extent e=3, and Packet 11 has e=2. There are two different reordering discontinuities, one at Packet 6 (where j=4) and one at Packet 12 (where j'=11).
パケット4の範囲E = 2、パケット5にはe = 3、パケット11のe = 2があります。2つの異なる並べ替えの不連続性があります。1つはパケット6（J = 4）に、もう1つはパケット12（ここではj = 11）です。
According to the definition of Reordering Gap
Gap(s[j']) = (j') - (j)
Gap(Packet 12) = (11) - (4) = 7
We also have three reordering-free runs of lengths 5, 0, and 5.
また、長さ5、0、および5の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.
ここでは、これら2つの複数イベントメトリックの違いが明らかです。ギャップは、その後、不連続性の並べ替えとして定義されるシーケンスの不連続性間の距離であり、並べ替えフリーの実行は、並べ替えられたパケット間の距離をキャプチャします。
This metric requires a stream of packets sent from one host (source) to another host (destination) through intervening networks. This method could be abused for denial-of-service attacks directed at destination and/or the intervening network(s).
このメトリックには、介在するネットワークを介して、あるホスト（ソース）から別のホスト（宛先）に送信されるパケットのストリームが必要です。この方法は、目的地や介入ネットワークに向けられたサービス拒否攻撃のために乱用される可能性があります。
Administrators of the source, destination, and intervening network(s) should establish bilateral or multilateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed between the participants may be cause for immediate rejection or discard of packets or other escalation procedures defined between the affected parties.
ソース、目的地、および介入ネットワークの管理者は、サンプルメトリックの収集のタイミング、サイズ、頻度に関する二国間または多国間協定を確立する必要があります。参加者間で合意された条件を超えるこの方法の使用は、影響を受ける当事者間で定義されたパケットまたはその他のエスカレーション手順を即座に拒否したり、廃棄する原因である可能性があります。
Active use of this method generates packets for a sample, rather than taking samples based on user data, and does not threaten user data confidentiality. Passive measurement must restrict attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential. In most cases, a hashing function will produce a value suitable for payload comparisons.
このメソッドを積極的に使用すると、ユーザーデータに基づいてサンプルを採取するのではなく、サンプル用のパケットを生成し、ユーザーデータの機密性を脅かすことはありません。パッシブ測定は、関心のあるヘッダーへの注意を制限する必要があります。ユーザーのペイロードは長さ分析のために一時的に保存される可能性があるため、この情報を安全かつ機密に保つために適切な予防措置を講じる必要があります。ほとんどの場合、ハッシュ関数はペイロード比較に適した値を生成します。
It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g., increasing or decreasing delay) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement. The likely consequences of packet injection are that the additional packets would be declared duplicates, or that the original packets would be seen as duplicates (if they arrive after the corresponding injected packets), causing invalid measurements on the injected packets.
特定のパケットまたはパケットのストリームがサンプルの一部であることを特定することが可能かもしれません。目的地や介入ネットワークでのその知識により、測定されたパフォーマンスを歪める可能性のあるパケットの処理（たとえば、遅延の増加または減少）を変更することができます。サンプルメトリックの一部であると思われる追加のパケットを生成することも可能です。これらの追加のパケットは、サンプル測定の結果を乱す可能性があります。パケットインジェクションの可能性のある結果は、追加のパケットが複製と宣言されるか、元のパケットが重複と見なされ（対応する注入パケットの後に到着した場合）、注入されたパケットに無効な測定を引き起こすことです。
The requirements for data collection resistance to interference by malicious parties and mechanisms to achieve such resistance are available in other IPPM memos. A set of requirements for a data collection protocol can be found in [RFC3763], and a protocol specification for the One-Way Active Measurement Protocol (OWAMP) is 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メトリックレジストリに登録されています。
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
ietfreordingbyteOffsetオブジェクトアイデンティティステータス現在の説明
"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オブジェクトアイデンティティステータス現在の説明
"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] Postel、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.
[RFC3148] Mathis、M。およびM. Allman、「経験的バルク容量メトリックを定義するためのフレームワーク」、RFC 3148、2001年7月。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002.
[RFC3432] Raisanen、V.、Grotefeld、G。、およびA. Morton、「定期的なストリームによるネットワークパフォーマンス測定」、RFC 3432、2002年11月。
[RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active Measurement Protocol (OWAMP) Requirements", RFC 3763, April 2004.
[RFC3763] Shalunov、S。およびB. Teitelbaum、「一元配置活性測定プロトコル（OWAMP）要件」、RFC 3763、2004年4月。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148] Stephan、E。、「IPパフォーマンスメトリック（IPPM）メトリックレジストリ」、BCP 108、RFC 4148、2005年8月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zeckauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zeckauskas、「一元配置活性測定プロトコル（OWAMP）」、RFC 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. Savage、「測定パケット再注文」、ACM Sigcomm Internet Measurement Workshop 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.Bennett、C。Partridge、およびN. Shectman、「パケットの並べ替えは病理学的ネットワークの動作ではありません」、IEEE/ACMトランザクションオンネットワーク、Vol。7、いいえ。6、pp。789-798、1999年12月。
[Cia00] L. Ciavattone and A. Morton, "Out-of-Sequence Packet Parameter Definition (for Y.1540)", Contribution number T1A1.3/2000-047, October 30, 2000, http://home.comcast.net/~acmacm/IDcheck/0A130470.doc.
[CIA00] L. CiavattoneおよびA. Morton、「Y.1540の場合（Y.1540の場合）」、貢献番号T1A1.3/2000-047、2000年10月30日、http：//home.comcast.NET/〜ACMACM/IDCHECK/0A130470.DOC。
[Cia03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized Active Measurements on a Tier 1 IP Backbone," IEEE Communications Mag., pp. 90-97, June 2003.
[CIA03] L. Ciavattone、A。Morton、およびG. Ramachandran、「ティア1 IPバックボーンの標準化されたアクティブ測定」、IEEE Communications Mag。、pp。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 et al。、「Tier-1 IPバックボーンにおけるアウトシーケンスパケットの測定と分類」、ACM Sigcomm Internet Measurement Workshop 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 and H. Radha、「低ビトレートインターネットビデオストリーミングの測定研究」、ACM Sigcommインターネット測定ワークショップの議事録2001 2001年11月1〜2日、米国サンフランシスコ。
[Mat03] M. Mathis, J. Heffner, and R. Reddy, "Web100: Extended TCP Instrumentation for Research, Education and Diagnosis", ACM Computer Communications Review, Vol 33, Num 3, July 2003, http://www.web100.org/docs/mathis03web100.pdf.
[MAT03] M. Mathis、J。Heffner、およびR. Reddy、「Web100：研究、教育、診断のための拡張TCP計装」、ACM Computer Communications Review、Vol 33、Num 3、7月、http：// www。web100.org/docs/mathis03web100.pdf。
[Pax98] V. Paxson, "Measurements and Analysis of End-to-End Internet Dynamics," Ph.D. dissertation, U.C. Berkeley, 1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz.
[Pax98] V. Paxson、「エンドツーエンドのインターネットダイナミクスの測定と分析」、博士号論文、U.C。Berkeley、1997、ftp：//ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control ", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP渋滞制御」、RFC 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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、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] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、RFC 3393、2002年11月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（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] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（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. Banka、A。Bare、A。P。Jayasumana、「パケットシーケンスでの並べ替えの程度のメトリック」、Proc。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].
Appendix A. Example Implementations in C (Informative)
付録A. C（有益な）の実装の例
Two example c-code implementations of reordering definitions follow:
並べ替え定義の2つの例Cコードの実装は次のとおりです。
Example 1 n-reordering ============================================
#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)
/*
* 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>
#define MAXN 100
#define min(a, b) ((a) < (b)? (a): (b))
#define loop(x) ((x) >= 0? x: x + MAXN)
/* Global counters */
int receive_packets=0; /* number of received */
int reorder_packets_Al=0; /* num reordered pkts (singleton) */
int reorder_packets_Stas=0; /* num reordered pkts(n-reordering)*/
/* 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標準：ISBN：0-470-84573-2、ハードカバー、558ページ、2003年9月。
Appendix B. Fragment Order Evaluation (Informative)
付録B. フラグメントオーダー評価（有益）
Section 3 stated that fragment reassembly is assumed prior to order evaluation, but that similar procedures could be applied prior to reassembly. This appendix gives definitions and procedures to identify reordering in a packet stream that includes fragmentation.
セクション3では、フラグメントの再組み立ては注文評価の前に想定されているが、同様の手順を再組み立て前に適用できると述べた。この付録は、断片化を含むパケットストリームでの並べ替えを特定するための定義と手順を示しています。
The Metric retains the same name, Type-P-Reordered, but additional parameters are required.
メトリックは同じ名前を保持し、タイプ-Preordedですが、追加のパラメーターが必要です。
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.
この付録は、パケットをフラグメントに分割するデバイスが、昇順のフラグメントオフセットに従ってそれらを送信することを前提としています。Early Linux OSは逆順序でフラグメントを送信したため、この可能性はチェックする価値があります。
+ 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 Octetユニット（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.
欠落したフラグメントを備えたパケットは失われたと宣言する必要があり、到着するフラグメントの並べ替えステータスは、サンプルメトリックから除外する必要があることに注意してください。
The value of Type-P-Reordered is typically false (the packet is in-order) when
タイプ-Preordedの値は通常、false（パケットは次の順序です）
* the sequence number s >= NextExp, AND
* シーケンス番号s> = nextexp、および
* the fragment offset FragOffset >= NextExpFrag
* フラグメントオフセットfrageffset> = nextexpfrag
However, it is more efficient to define reordered conditions exactly and designate Type-P-Reordered as False otherwise.
ただし、並べ替えられた条件を正確に定義し、それ以外の場合は誤っていると誤った型を指定する方が効率的です。
The value of Type-P-Reordered is defined as True (the packet is reordered) under the conditions below. In these cases, the NextExp value does not change.
Type-P-Reorderedの値は、以下の条件下でTrue（パケットが再注文された）として定義されます。これらの場合、nextExp値は変更されません。
Case 1: if s < NextExp
ケース1：s <nextexpの場合
Case 2: if s < FragSeq#
Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag
This definition can also be illustrated in pseudo-code. A version of the code follows, and some simplification may be possible. Housekeeping for the new parameters will be challenging.
この定義は、擬似コードにも示すことができます。コードのバージョンが続き、いくつかの単純化が可能になる場合があります。新しいパラメーターのハウスキーピングは困難です。
NextExp=0;
NextExpFrag=0;
FragSeq#=0;
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.
コードの動作バージョンには、サンプルメトリックなど、再注文ステータスをさらに使用する前に、パケットのすべてのフラグメントが到着することを確認するためのチェックが含まれます。
All fragments with the same source sequence number are assigned the same source time.
同じソースシーケンス番号を持つすべてのフラグメントには、同じソース時間が割り当てられます。
Evaluation with byte stream numbering may be simplified if the fragment offset is simply added to the SourceByte of the first packet (with fragment offset = 0), keeping the 8 octet units of the offset in mind.
フラグメントオフセットが最初のパケットのソースバイト（フラグメントオフセット= 0）のソースバイトに単純に追加され、オフセットの8オクテット単位を念頭に置いて念頭に置いている場合、バイトストリーム番号の評価を簡素化する場合があります。
Regarding this entire document or any portion of it (including the pseudo-code and C code), the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.
このドキュメント全体またはその一部（擬似コードとCコードを含む）に関して、著者は保証を行いませんし、その使用に起因する損害について責任を負いません。著者は、再配分されたデリバティブ作業に誤解を招く著者またはバージョン情報が含まれていない限り、他の人がそれを使用、変更、および配布する権利を減少させない方法で使用、変更、および配布する人に取消不能の許可を認めます。デリバティブ作業は、同様の条件でライセンスされる必要はありません。
Authors' Addresses
著者のアドレス
Al Morton AT&T Labs Room D3 - 3C06 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 1571 EMail: acmorton@att.com
Al Morton AT＆T Labs Room D3-3C06 200 Laurel Ave. South Middletown、NJ 07748 USA電話1 732 420 1571メール：acmorton@att.com
Len Ciavattone AT&T Labs Room A2 - 4G06 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 1239 EMail: lencia@att.com
Len Ciavattone AT＆T LabsルームA2-4G06 200 Laurel Ave. South Middletown、NJ 07748 USA Phone 1 732 420 1239メール：lencia@att.com
Gomathi Ramachandran AT&T Labs Room C4 - 3D22 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 2353 EMail: gomathi@att.com
Gomathi Ramachandran AT＆T Labs Room C4-3D22 200 Laurel Ave. South Middletown、NJ 07748 USA電話1 732 420 2353メール：gomathi@att.com
Stanislav Shalunov Internet2 1000 Oakbrook DR STE 300 Ann Arbor, MI 48104 Phone: +1 734 995 7060 EMail: shalunov@internet2.edu
Stanislav Shalunov Internet2 1000 Oakbrook Dr Ste 300 Ann Arbor、MI 48104電話：1 734 995 7060メール：shalunov@internet2.edu
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton, OR 97008 USA Phone: +1 818 338 4112 EMail: jperser@veriwave.com
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton、または97008 USA電話：1 818 338 4112メール：jperser@veriwave.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。