RFC4737 日本語訳
4737 Packet Reordering Metrics. A. Morton, L. Ciavattone, G.Ramachandran, S. Shalunov, J. Perser. November 2006. (Format: TXT=94699 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループA.モートンの要求をネットワークでつないでください: 4737年のL.Ciavattoneカテゴリ: 標準化過程G.ラマチャンドランAT&T研究室S.Shalunov Internet2J.Perser Veriwave2006年11月
Packet Reordering Metrics
パケットReordering測定基準
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このメモは、ネットワークがパケットごとのベースに関するパケットオーダーを維持したかどうか評価するために測定基準を定義します。 それは、新しい測定基準に関する動機を提供して、すべての測定基準に必要である文脈情報を含む測定問題について議論します。 メモは、最初に再命令された単独個体を定義して、次に、サンプル測定基準がネットワーク特殊化か受信機デザインのために数個の役に立つ寸法で再命令する範囲を定量化する基礎としてそれを使用します。 追加測定基準は再命令の頻度と別々の発生の間の距離を定量化します。 次に、私たちはメートル法でaを定義します。TCPにおける再命令効果の査定に向かって指向しています。 様々なサンプル測定基準を使用する評価のいくつかの例が含まれています。 付録はパケット断片化でオーダーを評価するための拡張定義を与えます。
Morton, et al. Standards Track [Page 1] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Motivation .................................................4
1.2. Goals and Objectives .......................................5
1.3. Required Context for All Reordering Metrics ................6
2. Conventions Used in this Document ...............................7
3. A Reordered Packet Singleton Metric .............................7
3.1. Metric Name ................................................8
3.2. Metric Parameters ..........................................8
3.3. Definition .................................................8
3.4. Sequence Discontinuity Definition ..........................9
3.5. Evaluation of Reordering in Dimensions of Time or Bytes ...10
3.6. Discussion ................................................10
4. Sample Metrics .................................................11
4.1. Reordered Packet Ratio ....................................11
4.1.1. Metric Name ........................................11
4.1.2. Metric Parameters ..................................11
4.1.3. Definition .........................................12
4.1.4. Discussion .........................................12
4.2. Reordering Extent .........................................12
4.2.1. Metric Name ........................................12
4.2.2. Notation and Metric Parameters .....................12
4.2.3. Definition .........................................13
4.2.4. Discussion .........................................13
4.3. Reordering Late Time Offset ...............................14
4.3.1. Metric Name ........................................14
4.3.2. Metric Parameters ..................................14
4.3.3. Definition .........................................15
4.3.4. Discussion .........................................15
4.4. Reordering Byte Offset ....................................16
4.4.1. Metric Name ........................................16
4.4.2. Metric Parameters ..................................16
4.4.3. Definition .........................................16
4.4.4. Discussion .........................................17
4.5. Gaps between Multiple Reordering Discontinuities ..........17
4.5.1. Metric Names .......................................17
4.5.2. Parameters .........................................17
4.5.3. Definition of Reordering Discontinuity .............17
4.5.4. Definition of Reordering Gap .......................18
4.5.5. Discussion .........................................18
4.6. Reordering-Free Runs ......................................19
4.6.1. Metric Names .......................................19
4.6.2. Parameters .........................................19
4.6.3. Definition .........................................19
4.6.4. Discussion and Illustration ........................20
1. 序論…4 1.1. 動機…4 1.2. 目標と目的…5 1.3. すべてのReordering測定基準のために文脈を必要とします…6 2. このDocumentのコンベンションUsed…7 3. A Reordered PacketシングルトンMetric…7 3.1. メートル法の名前…8 3.2. メートル法のパラメタ…8 3.3. 定義…8 3.4. 系列不連続定義…9 3.5. 時間かバイトの次元における、Reorderingの評価…10 3.6. 議論…10 4. 測定基準を抽出してください…11 4.1. パケット比をReorderedしました…11 4.1.1. メートル法の名前…11 4.1.2. メートル法のパラメタ…11 4.1.3. 定義…12 4.1.4. 議論…12 4.2. 範囲をReorderingします…12 4.2.1. メートル法の名前…12 4.2.2. 記法とメートル法のパラメタ…12 4.2.3. 定義…13 4.2.4. 議論…13 4.3. 時間後半をReorderingするのは相殺されました…14 4.3.1. メートル法の名前…14 4.3.2. メートル法のパラメタ…14 4.3.3. 定義…15 4.3.4. 議論…15 4.4. バイトをReorderingするのは相殺されました…16 4.4.1. メートル法の名前…16 4.4.2. メートル法のパラメタ…16 4.4.3. 定義…16 4.4.4. 議論…17 4.5. 複数のReordering不連続のギャップ…17 4.5.1. メートル法の名前…17 4.5.2. パラメタ…17 4.5.3. Reordering不連続の定義…17 4.5.4. Reorderingギャップの定義…18 4.5.5. 議論…18 4.6. 無Reorderingの走行…19 4.6.1. メートル法の名前…19 4.6.2. パラメタ…19 4.6.3. 定義…19 4.6.4. 議論とイラスト…20
Morton, et al. Standards Track [Page 2] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[2ページ]。
5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric ..21
5.1. Metric Name ...............................................21
5.2. Parameter Notation ........................................21
5.3. Definitions ...............................................22
5.4. Discussion ................................................22
6. Measurement and Implementation Issues ..........................23
6.1. Passive Measurement Considerations ........................26
7. Examples of Arrival Order Evaluation ...........................26
7.1. Example with a Single Packet Reordered ....................26
7.2. Example with Two Packets Reordered ........................28
7.3. Example with Three Packets Reordered ......................30
7.4. Example with Multiple Packet Reordering Discontinuities ...31
8. Security Considerations ........................................32
8.1. Denial-of-Service Attacks .................................32
8.2. User Data Confidentiality .................................32
8.3. Interference with the Metric ..............................32
9. IANA Considerations ............................................33
10. Normative References ..........................................35
11. Informative References ........................................36
12. Acknowledgements ..............................................37
Appendix A. Example Implementations in C (Informative) ............38
Appendix B. Fragment Order Evaluation (Informative) ...............41
B.1. Metric Name ...............................................41
B.2. Additional Metric Parameters ..............................41
B.3. Definition ................................................42
B.4. Discussion: Notes on Sample Metrics When Evaluating
Fragments .................................................43
Appendix C. Disclaimer and License ................................43
5. 測定基準は受信機査定に焦点を合わせました: TCP関連する、メートル法です。21 5.1. メートル法の名前…21 5.2. パラメタ記法…21 5.3. 定義…22 5.4. 議論…22 6. 測定と実現問題…23 6.1. 受け身の測定問題…26 7. 到着に関する例は評価を注文します…26 7.1. 独身のパケットReorderedがある例…26 7.2. 2パケットReorderedがある例…28 7.3. 3パケットReorderedがある例…30 7.4. 複数のパケットReordering不連続がある…例31 8. セキュリティ問題…32 8.1. サービス不能攻撃…32 8.2. 利用者データ秘密性…32 8.3. メートル法の干渉…32 9. IANA問題…33 10. 標準の参照…35 11. 有益な参照…36 12. 承認…37 C(有益な)での付録A.例の実現…38付録B.はオーダー評価(有益な)を断片化します…41 B.1。 メートル法の名前…41 B.2。 追加メートル法のパラメタ…41 B.3。 定義…42 B.4。 議論: 断片を評価するとき、サンプル測定基準では、注意します。43の付録C.注意書きとライセンス…43
Morton, et al. Standards Track [Page 3] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[3ページ]。
1. Introduction
1. 序論
Ordered arrival is a property found in packets that transit their path, where the packet sequence number increases with each new arrival and there are no backward steps. The Internet Protocol [RFC791] [RFC2460] has no mechanisms to ensure either packet delivery or sequencing, and higher-layer protocols (above IP) should be prepared to deal with both loss and reordering. This memo defines reordering metrics.
命令された到着はパケットでそのトランジットがそれらの経路であることが特性によってわかったということです。(そこには、各出生に従って、パケット一連番号が増加して、どんな後方のステップもありません)。 インターネットプロトコル[RFC791][RFC2460]には、パケット配信か配列のどちらかを確実にするメカニズムが全くありません、そして、上位層プロトコル(IPの上の)は損失と再命令の両方に対処するように準備されるべきです。 このメモは再命令測定基準を定義します。
A unique sequence identifier carried in each packet, such as an incrementing consecutive integer message number, establishes the source sequence.
増加している連続した整数メッセージ番号などの各パケットで運ばれたユニーク配列識別子はソース系列を確立します。
The detection of reordering at the destination is based on packet arrival order in comparison with a non-reversing reference value [Cia03].
目的地で再命令する検出は非の逆にする基準値[Cia03]との比較におけるパケット到着命令に基づいています。
This metric is consistent with [RFC2330] and classifies arriving packets with sequence numbers smaller than their predecessors as out-of-order or reordered. For example, if sequentially numbered packets arrive 1,2,4,5,3, then packet 3 is reordered. This is equivalent to Paxon's reordering definition in [Pax98], where "late" packets were declared reordered. The alternative is to emphasize "premature" packets instead (4 and 5 in the example), but only the arrival of packet 3 distinguishes this circumstance from packet loss. Focusing attention on late packets allows us to maintain orthogonality with the packet loss metric. The metric's construction is very similar to the sequence space validation for received segments in [RFC793]. Earlier work to define ordered delivery includes [Cia00], [Ben99], [Lou01], [Bel02], [Jai02], and [Cia03].
これほどメートル法、[RFC2330]と一致していて、一連番号が彼らの前任者よりわずかな状態で故障するか再命令されるとして到着パケットを分類します。 例えば、連続して付番されたパケットが到着するなら、1、2、4、5、3、当時のパケット3は再命令されます。 これはPaxonが[Pax98]で定義を再命令するのに同等です。(そこでは、「遅い」パケットが再命令されていると宣言されました)。 代替手段が代わりに(例の4と5)「時期尚早な」パケットを強調することですが、パケット3の到着だけがパケット損失とこの状況を区別します。 遅いパケットに注意の焦点を合わせるのに、パケット損失がメートル法で私たちは直交性を維持できます。 メートル法による構造が[RFC793]の容認されたセグメントのための系列宇宙合法化と非常に同様であるということです。 命令された配送を定義する以前の仕事は[Cia00]、[Ben99]、[Lou01]、[Bel02]、[Jai02]、および[Cia03]を含んでいます。
1.1. Motivation
1.1. 動機
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.
ほとんどのアプリケーションにおいて関連しています、特にネットワークを評価するときにはレアル-時間メディアのために流れを支持してください。A再命令メートル法、再命令の範囲は、容認されたパケットが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つ(さらに)の経路がただ一つのパケットの流れか流れを支持すると、より長い経路を横断するパケットは故障していた状態で到着するかもしれません。 複数の経路が、ロードバランシングを達成するのに使用されるか、またはルートの不安定性から起こるかもしれません。
Morton, et al. Standards Track [Page 4] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[4ページ]。
* 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.
目的地で秩序を回復する能力には、有限限界がおそらくあるでしょう。 実用的なホストには、パケット、バイト、または時間(反-ジターバッファなどの)に関して有限サイズがある受信機バッファがあります。 いったん再命令の初期の決断をすると、再命令、または遅れの範囲を定量化するのは役に立ちます、すべての重要な寸法で。
1.2. Goals and Objectives
1.2. 目標と目的
The definitions below intend to satisfy the goals of:
以下での定義は目標を満たすつもりです:
1. Determining whether or not packet reordering has occurred.
1. パケット再命令が起こったかどうか決定します。
2. Quantifying the degree of reordering. (We define a number of
metrics to meet this goal, because receiving procedures differ
by protocol or application. Since the effects of packet
reordering vary with these procedures, a metric that quantifies
a key aspect of one receiver's behavior could be irrelevant to
2. 再命令の度を定量化します。 私たちはこの目標を達成するために多くの測定基準を定義します、受信手順がプロトコルかアプリケーションで異なるので。(以来これらの手順、aに従ってパケットが再命令されるという効果がメートル法であることで異なる、それは振舞いが無関係であるかもしれない1台の受信機の特徴を定量化します。
Morton, et al. Standards Track [Page 5] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[5ページ]。
a different receiver. If all the metrics defined below are
reported, they give a wide-ranging view of reordering
conditions.)
a異なった受信機以下で定義されたすべての測定基準が報告されるなら、それらが再命令状態の広範囲の意見を与える、)
Reordering Metrics MUST:
測定基準をReorderingするのはそうしなければなりません:
+ 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:
Reordering Metricsには以下の属性の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.
現在のセットの測定基準は、上記のすべての必要条件を満たして、連結属性以外のすべてを提供します(ケースを除いて中経路セグメントの測定値が再命令でないのを示して、また、これらのセグメントで構成された完全な経路が再命令でないのを示すと見積もるかもしれない)。 しかしながら、これらの目標を満たすと、測定基準のセットはネットワーク特殊化か受信機デザインに関する何らかの明確な洞察を提供するものに制限されます。 それらはそれらのアプリケーションへの再命令効果の適用範囲で徹底的である傾向がありません、そして、追加測定値は可能であるかもしれません。
1.3. Required Context for All Reordering Metrics
1.3. すべてのReordering測定基準のための必要な文脈
A critical aspect of all reordering metrics is their inseparable bond with the measurement conditions. Packet reordering is not well defined unless the full measurement context is reported. Therefore, all reordering metric definitions include the following parameters:
測定基準をすべて再命令するきわどい局面は測定状態とのそれらの不可分の債券です。 完全な測定関係が報告されない場合、パケット再命令はよく定義されません。 したがって、すべて再命令しているメートル法の定義は以下のパラメタを含んでいます:
1. The "Packet of Type-P" [RFC2330] identifiers for the packet
stream, including the transport addresses for source and
destination, and any other information that may result in
different packet treatments.
1. パケットのための「タイプPのパケット」[RFC2330]識別子は流れます、ソースと目的地への輸送アドレス、および異なったパケット処理をもたらすかもしれないいかなる他の情報も含んでいて。
Morton, et al. Standards Track [Page 6] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[6ページ]。
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.
いつ、aメートル法であることは、報告されていて、結果のための文脈を提供するためにこれらのパラメタの記述を含まなければならないということであるか。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different implementations are comparable, and to note instances when an implementation could perturb the network.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか? RFC2119は念頭にプロトコルで書かれましたが、キーワードは本書では同様の理由に使用されます。 実現がネットワークを混乱させることができたとき、それらは2つの異なった実現からの測定値の結果が匹敵しているのを保証して、例に注意するのにおいて使用されています。
In this memo, the characters "<=" should be read as "less than or equal to" and ">=" as "greater than or equal to".
“greater than or equal to"としてのこのメモ、「<=」が“less than or equal to"が読み込まれるべきであるキャラクタ、および「>=」で。
3. A Reordered Packet Singleton Metric
3. A Reordered PacketシングルトンMetricです。
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.
'単独個体'で、メートル法であり、私たちはある意味で原子である測定基準を示します。 例えば、1人のホストから別のホストまでの「大量の処理能力」のただ一つの例は単独個体とメートル法で定義されるかもしれません、例が、多くのインターネットパケットのタイミングを測定することを伴いますが。
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.
パケットオーダーの評価は、概念を支持しながら、数個を必要とします。 1番目が唯一パケット伝送の注文を証明するためにソースでパケットに適用された一連の厳密に単調に増加する識別子を作り出すアルゴリズム(機能)である、(g(x)、aが機能するところでは、何かx>y、g(x)>gのために厳密に単調に増加するのが、(y) )ですか? ユニーク配列識別子は、単に増加している連続した整数メッセージ番号、または以下で使用される一連番号であるかもしれません。 セクション6で一連番号ロールオーバーの見通しについて議論します。
The second supporting concept is a stored value that is the "next expected" packet number. Under normal conditions, the value of Next Expected (NextExp) is the sequence number of the previous packet plus 1 for message numbering. (In general, the receiver reproduces the
概念を支持する秒は「予想された次」パケット番号である格納された値です。 正常な状況では、Next Expected(NextExp)の値は、前のパケットの一連番号とメッセージ付番のための1です。 (一般に、受信機は再生します。
Morton, et al. Standards Track [Page 7] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[7ページ]。
sender's algorithm and the sequence of identifiers so that the "next expected" can be determined.)
識別子の送付者のアルゴリズムと系列、断固としている、)。
Each packet within a packet stream can be evaluated with this order singleton metric.
このオーダー単独個体がメートル法でパケットの流れの中の各パケットを評価できます。
3.1. Metric Name
3.1. メートル法の名前
Type-P-Reordered
タイプ-P-Reordered
3.2. Metric Parameters
3.2. メートル法のパラメタ
+ Src, the IP address of a host.
+ Src、ホストのIPアドレス。
+ Dst, the IP address of a host.
+ Dst、ホストのIPアドレス。
+ SrcTime, the time of packet emission from the source (or wire
time).
+SrcTime、ソース(または、ワイヤ時間)からのパケット放出の時間。
+ s, the unique packet sequence number applied at the source, in
units of messages.
+ s、ユニットのメッセージのソースで適用されたユニークなパケット一連番号。
+ NextExp, the next expected sequence number at the destination, in
units of messages. The stored value in NextExp is determined from
a previously arriving packet.
+ NextExp、ユニットのメッセージの目的地の次の予想された一連番号。 NextExpの格納された値は以前に到着しているパケットから決定しています。
And optionally:
そして、任意に:
+ PayloadSize, the number of bytes contained in the information
field and referred to when the SrcByte sequence is based on bytes
transferred.
+ PayloadSize、情報フィールドに保管されていて、SrcByte系列がバイトに基づいているとき言及されたバイト数は移されました。
+ SrcByte, the packet sequence number applied at the source, in
units of payload bytes.
+ SrcByte、ソースでユニットのペイロードバイトで適用されたパケット一連番号。
3.3. Definition
3.3. 定義
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値との比較で再命令されるのがわかっているなら、Type-P-Reorderedは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.
Type-P-Reorderedの値は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.
s>がNextExpと等しいなら(パケットは整然としています)、Type-P-Reorderedの値はFALSEと定義されます。 この場合、NextExpは到着する次のパケットとの比較のために+1にsに用意ができています。
Morton, et al. Standards Track [Page 8] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[8ページ]。
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
s>がNextExpと等しいなら、/*sはオーダーにおける*/NextExp=s+1です。 タイプ-P-Reorderedは偽と等しいです。 ほかの/*いつs<NextExpタイプ*/P-Reordered、本当に等しさ
3.4. Sequence Discontinuity Definition
3.4. 系列不連続定義
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があるパケットはオーダーにおける配送の特別なケースです。 この状態はパケット損失か再命令のどちらかのために系列不連続を示します。 Reorderedパケットは、系列不連続が再命令不連続と定義されるために到着しなければなりません(セクション4を見てください)。
We define two different states for in-order packets.
私たちはオーダーにおけるパケットのために2つの異なった州を定義します。
When s = NextExp, the original sequence has been maintained, and there is no discontinuity present.
sがNextExpと等しいときに、元の系列は維持されました、そして、どんな存在している不連続もありません。
When s > NextExp, some packets in the original sequence have not yet arrived, and there is a sequence discontinuity associated with packet s. The size of the discontinuity is s - NextExp, equal to the number of packets presently missing, either reordered or lost.
s>NextExpであるときに、元の系列のいくつかのパケットはまだ到着していません、そして、パケットsに関連している系列不連続があります。 不連続のサイズは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;
s>がNextExpと等しいなら、s>のNextExpの当時のSequenceDiscontinutyであるなら、/*sは= 本当にオーダーで*/です。 SeqDiscontinutySizeはsと等しいです--NextExp ほかに、SequenceDiscontinutyは偽と等しいです。 NextExp=s+1。 タイプ-P-Reorderedは偽と等しいです。
else /* when s < NextExp */
Type-P-Reordered = True;
SequenceDiscontinuty = False;
ほかの/*いつs<NextExpタイプ*/P-Reordered、= 本当に。 SequenceDiscontinutyは偽と等しいです。
Morton, et al. Standards Track [Page 9] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[9ページ]。
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.
何か系列不連続が起こるかどうかが(そして、それらのサイズ)、損失をもたらす状態で断固としている、そして/または、測定経路に沿って再命令します。 パケットが1ポイントで再命令されて、次に、経路のほかの場所で失われる場合がありましたが、目的地での観測からこれを知ることができないことに注意してください。
3.5. Evaluation of Reordering in Dimensions of Time or Bytes
3.5. 時間かバイトの次元における、Reorderingの評価
It is possible to use alternate dimensions of time or payload bytes to test for reordering in the definition of Section 3.3, as long as the SrcTimes and SrcBytes are unique and reliable. Sequence Discontinuities are easily defined and detected with message numbering; however, this is not so simple in the dimensions of time or bytes. This is a detractor for the alternate dimensions because the sequence discontinuity definition plays a key role in the sample metrics that follow.
セクション3.3の定義で再命令するのがないかどうかテストするのに時間かペイロードバイトの交互の次元を使用するのは可能です、SrcTimesとSrcBytesがユニークであって、信頼できる限り。 系列Discontinuitiesは容易に定義されて、メッセージ付番で検出されます。 しかしながら、これは時間かバイトの次元でそれほど簡単ではありません。 系列不連続定義が従うサンプル測定基準で重要な役割を果たすので、これは交互の寸法のための中傷者です。
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で説明されるように。
3.6. Discussion
3.6. 議論
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がUndefined(到着パケットが最初のうまくいっている転送であるので)である場合では、パケットは整然とした状態で(タイプ-P-Reordered=FALSE)指定されます。
This metric assumes reassembly of packet fragments before evaluation. In principle, it is possible to use the Type-P-Reordered metric to evaluate reordering among packet fragments, but each fragment must contain source sequence information. See Appendix B, "Fragment Order Evaluation", for more detail.
これほどメートル法、評価の前にパケット断片の再アセンブリであると仮定します。 原則として、パケット断片の中で再命令する評価するためにはメートル法のType-P-Reorderedを使用するのが可能ですが、各断片はソース系列情報を含まなければなりません。 Appendix B、「断片オーダー評価」をその他の詳細に関して見てください。
Morton, et al. Standards Track [Page 10] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[10ページ]。
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.
写しパケット(複数の非不正なコピー)が目的地に到着するなら、それらに注意しなければなりません、そして、到着する1番目だけがさらなる分析のために考えられます(コピーは上の定義に従って再命令されていると申告されるでしょう)。 この要件は、以前のIPPM測定基準と同じ格納意味を持って、[RFC2679]の先例に従います。 私たちは、MeasurementとImplementation Issuesでセクション6で必要である格納サイズを最小にするために提案を提供します。
4. Sample Metrics
4. サンプル測定基準
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.
このセクションで、私たちはただ一つのソース一連番号システムからパケットのサンプルに適切な測定基準を定義します。 それが再命令が起こるか、パケットが故障している程度について断言するのにおいて非常に望ましいかまたは敬意他のパケットで再命令されていると。 このセクションは様々な単位の測定で再命令する範囲を定量化するいくつかの測定基準を定義します。 それぞれのメートル法のハイライトa関連している使用。
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.
以下の小区分における測定基準は、ネットワーク特殊化オリエンテーションを持っていますが、補償を再命令するのは興味がある受信機デザインに関連性をまた持っています。 私たちは簡単な比率メートル法の表示によるサンプルの再命令された部分を始めます。
4.1. Reordered Packet Ratio
4.1. パケット比をReorderedしました。
4.1.1. Metric Name
4.1.1. メートル法の名前
Type-P-Reordered-Ratio-Stream
タイプP-Reordered比率の流れ
4.1.2. Metric Parameters
4.1.2. メートル法のパラメタ
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:
パラメタセットはType-P-Reordered単独個体パラメタを含んでいます。 ポアソンの流れ([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と等しいように同一の複製物(写し)を取り除いてあると思い出してください。
Morton, et al. Standards Track [Page 11] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[11ページ]。
+ R, the ratio of reordered packets to received packets, defined
below
+ R、再命令されたパケット対以下で定義された容認されたパケットの比率
Note that parameter dT is effectively the threshold for declaring a packet as lost. The IPPM Packet Loss Metric [RFC2680] declines to recommend a value for this threshold, saying instead that "good engineering, including an understanding of packet lifetimes, will be needed in practice."
事実上、パラメタdTが失われているようにパケットを宣言するための敷居であることに注意してください。 IPPM Packet Loss Metric[RFC2680]は、この敷居のために値を推薦するのを断ります、代わりに「パケット生存期間の理解を含む良い工学が実際には必要でしょう」と言って。
4.1.3. Definition
4.1.3. 定義
Given a stream of packets sent from a source to a destination, the ratio of reordered packets in the sample is
ソースから目的地に送られたパケットの流れを考えて、サンプルの再命令されたパケットの比率は考えます。
R = (Count of packets with Type-P-Reordered=TRUE) / ( L )
Rは/と等しいです(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で、増えてください)。 写しパケットのケース第一刷だけが使用されていることに注意してください。
4.1.4. Discussion
4.1.4. 議論
When the Type-P-Reordered-Ratio-Stream is zero, no further reordering metrics need be examined for that sample. Therefore, the value of this metric is its simple ability to summarize the results for a reordering-free sample.
Type-P-Reordered比率の流れがゼロであるときに、これ以上測定基準を再命令しないのはそのサンプルがないかどうか調べられなければなりません。 したがって、これほどメートル法の値は無再命令のサンプルのために結果をまとめる簡単な性能です。
4.2. Reordering Extent
4.2. 範囲をReorderingします。
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.
このセクションは、パケットが再命令される範囲を定義して、特定の系列不連続をそれぞれの再命令されたパケットに関連づけます。 このセクションは上で定義されたParametersを引き継ぎます。
4.2.1. Metric Name
4.2.1. メートル法の名前
Type-P-Packet-Reordering-Extent-Stream
タイプPパケットReordering範囲の流れ
4.2.2. Notation and Metric Parameters
4.2.2. 記法とメートル法のパラメタ
Recall that K is the number of packets in the stream at the source, and L is the number of packets received at the destination.
Kがソースにおける流れにおいて、パケットの数であり、Lが目的地に受け取られたパケットの数であると思い出してください。
Each packet has been assigned a sequence number, s, a consecutive integer from 1 to K in the order of packet transmission (at the source).
各パケットに一連番号を割り当ててあります、s、パケット伝送(ソースの)の注文における連続した1〜Kまでの整数。
Let s[1], s[2], ..., s[L] represent the original sequence numbers associated with the packets in order of arrival.
s[1]、s[2]、…をさせてください。, s[L]は到着順にパケットに関連している元の一連番号を表します。
Morton, et al. Standards Track [Page 12] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[12ページ]。
s[i] can be thought of as a vector, where the index i is the arrival position of the packet with sequence number s. In theory, any source sequence number could appear in any arrival position, but this is unlikely in reality.
ベクトルとしてs[i]を考えることができます、どこ、インデックス、iは一連番号sがあるパケットの到着位置であるか。 理論上、どんなソース一連番号もどんな到着位置にも現れることができましたが、これはほんとうはありそうもないです。
Consider a reordered packet (Type-P-Reordered=TRUE) with arrival index i and source sequence number s[i]. There exists a set of indexes j (1 <= j < i) such that s[j] > s[i].
再命令されたパケットが到着インデックスiとソース一連番号s[i]がある(タイプ-P-Reordered=TRUE)であると考えてください。 インデックスjで設定している(1<がj<iと等しい)そのようなものは存在しています。そのs[j]>s[i]。
The new parameters are:
新しいパラメタは以下の通りです。
+ i, the index for arrival position, where i-1 represents an arrival
earlier than i.
+ i、到着位置へのインデックス。そこでは、i-1がiより早く到着を表します。
+ j, a set of one or more arrival indexes, where 1 <= j < i.
+ j、1つ以上の到着のセット(1<がj<iと等しい)は索引をつけます。
+ s[i], the original sequence numbers, s, in order of arrival.
+ s[i]、元の一連番号、到着の順にs。
+ e, the Reordering Extent, in units of packets, defined below.
+ e、以下で定義されたユニットのパケットのReordering Extent。
4.2.3. Definition
4.2.3. 定義
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]がjの最も小さい値のためのi-jがどこs[j]>s[i]であったかで定義されるパケットのe。
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.
範囲の定義を批評してください: いくつかの到着命令のために、再命令範囲が、受信機格納を過大評価する傾向があるので、簡単な位置/距離の課題は、秩序を回復する必要がありました。 パケット格納が少しもより早く引かれることになっていると見込むより正確で複雑な手順は受信機が上側の層に通過できたパケットを再命令しました(Byte Offsetがメートル法であることを見てください)。 偏見が理解されている状態で、この定義は特に「急いで」計算を要求する人に十分であると考えられます。
4.2.4. Discussion
4.2.4. 議論
The packet with index j (s[j], identified in the Definition above) is the reordering discontinuity associated with packet s at index i (s[i]). This definition is formalized below.
インデックスj(上でDefinitionで特定されたs[j])があるパケットは不連続がインデックスiでパケットsに関連づけた再命令です。(s[i])。 この定義は以下で正式にされます。
Morton, et al. Standards Track [Page 13] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[13ページ]。
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は再命令されたパケットが系列を完了するのを待っている間に受信機のバッファに保持しなければならないパケットの数を与えます。 より複雑なシナリオのために、範囲は必要な格納の過大評価であるかもしれません(セクション7でReordering Byte Offsetの上のセクション4.4と例を見てください)。 また、受信機パージであるなら、どんな理由、範囲における、メートル法のバッファもこの振舞いを反映しないでしょう、代わりに受信機が、秩序を回復するのを徹底的に試みると仮定して。
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.
サンプルが範囲を再命令するのは、容易に様々な範囲の頻度をまとめるためにヒストグラムとして言い表されるかもしれません。
4.3. Reordering Late Time Offset
4.3. 時間後半をReorderingするのは相殺されました。
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.
受信機がそれらを収容するために持たなければならないバッファ時間に関してそれらの遅れを示すオフセット値はReorderedパケットに割り当てることができます。 オフセット測定基準はセクション3のメートル法の再命令されたパケット単独個体によって特定されるように再命令されたパケットだけの上で計算されます。
4.3.1. Metric Name
4.3.1. メートル法の名前
Type-P-Packet-Late-Time-Stream
タイプのPパケットの遅い時間の流れ
4.3.2. Metric Parameters
4.3.2. メートル法のパラメタ
In addition to the parameters defined for Type-P-Reordered-Ratio- Stream, we specify:
Type-P-Reordered-比率流れのために定義されたパラメタに加えて、私たちは指定します:
+ 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]のオフセット)は以下で定義しました。
Morton, et al. Standards Track [Page 14] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[14ページ]。
4.3.3. Definition
4.3.3. 定義
Lateness in time is calculated using destination times. When received packet s[i] is reordered and has a reordering extent e, then:
時間内にの遅れは、目的地回を使用することで計算されます。 次に、容認されたパケットs[i]がいつかが、再命令している範囲eを再命令して、持っています:
LateTime(s[i]) = DstTime(i)-DstTime(i-e)
LateTime、(s[i])はDstTime(i)-DstTimeと等しいです。(i-e)
Alternatively, using similar notation to that of Section 4.2, an equivalent definition is:
あるいはまた、セクション4.2のものに同様の記法を使用して、同等な定義は以下の通りです。
LateTime(s[i]) = DstTime(i)-DstTime(j), for min{j|1<=j<i} that
satisfies s[j]>s[i].
LateTime、(s[i])はs[j]>s[i]を満たす分j| 1<=j<iのためのDstTime(i)-DstTime(j)と等しいです。
4.3.4. Discussion
4.3.4. 議論
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 Packet Delay Variation(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).
反-ジターバッファの場合には、事情が受信機が遅いパケットの意図している外でプレーする時に損失隠すことを使うところにあります。 しかしながら、このパケットが故障していた状態で到着するなら、Late Timeは、パケットがまだ役に立っているかどうか決定します。 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]であると仮定する場合、期待している到着時間はすべてのパケットのために定義されるかもしれませんが、これは、本質的にはa単一のポイント遅れ変化メートル法であって(ITU-T Recommendations[I.356]と[Y.1540]で定義されるように)、a再命令メートル法ではありません。
Morton, et al. Standards Track [Page 15] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[15ページ]。
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)が収容した累積分布関数は有益であるかもしれません。
4.4. Reordering Byte Offset
4.4. バイトをReorderingするのは相殺されました。
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.
受信機がそれらを収容するために持たなければならないバイトにおける格納を示すオフセット値はReorderedパケットに割り当てることができます。 オフセット測定基準はセクション3のメートル法の再命令されたパケット単独個体によって特定されるように再命令されたパケットだけの上で計算されます。
4.4.1. Metric Name
4.4.1. メートル法の名前
Type-P-Packet-Byte-Offset-Stream
Pパケットバイトオフセット・ストリームをタイプしてください。
4.4.2. Metric Parameters
4.4.2. メートル法のパラメタ
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]のオフセット
4.4.3. Definition
4.4.3. 定義
The Byte stream offset for reordered packet s[i] is the sum of the payload sizes of packets qualified by the following criteria:
再命令されたパケットs[i]のために相殺されたByteの流れは以下の評価基準によって資格があったパケットのペイロードサイズです:
* 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がある再命令されたパケットs[i]のために:
ByteOffset(s[i]) = Sum[qualified packets]
= Sum[PayloadSize(packet at i-1 if qualified),
PayloadSize(packet at i-2 if qualified), ...
PayloadSize(packet at i-e always qualified)]
ByteOffset、(s[i])=合計[適切なパケット]=合計[PayloadSize、(i-1のパケット、資格がある、)、PayloadSize、(i-2のパケット、資格がある、)、…PayloadSize(いつも資格があったi-eのパケット]
Using our earlier notation:
私たちの以前の記法を使用します:
ByteOffset(s[i]) =
Sum[payloads of s[j] where s[j]>s[i] and i > j >= i-e]
ByteOffset、(s[i])=合計[s[j]>s[i]とi>j>がi-eと等しいs[j]のペイロード]
Morton, et al. Standards Track [Page 16] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[16ページ]。
4.4.4. Discussion
4.4.4. 議論
We note that estimates of buffer size due to reordering depend greatly on the test stream, in terms of the spacing between test packets and their size, especially when packet size is variable. In these and other circumstances, it may be most useful to characterize offset in terms of the payload size(s) of stored packets, using the Type-P-packet-Byte-Offset-Stream metric.
私たちは、再命令によるバッファサイズの見積りをテストパケットとそれらのサイズの間のスペースに関してテストの流れに大いに依存することに注意します、特にパケットサイズが可変であるときに。 これらと他の事情では、格納されたパケットのペイロードサイズに関してオフセットを特徴付けるのは最も役に立つかもしれません、Type-Pパケットバイトオフセットの流れを使用して。メートル法。
The byte offset metric can help predict whether reordered packets will be useful in a general receiver buffer system with finite limits. The limit is expressed as the number of bytes the buffer can store.
メートル法で相殺されたバイトは、再命令されたパケットが有限限界がある一般的な受信機緩衝系で役に立つかどうかと予測するのを助けることができます。 限界はバッファが格納できるバイト数として言い表されます。
A sample's ByteOffset results may be expressed as a histogram to summarize the frequency of buffer lengths needed to accommodate reordered packets and permit buffer tuning on that basis. A CDF with buffer size vs. percent of reordered packets accommodated may be informative.
サンプルのByteOffset結果は、再命令されたパケットを収容するのに必要であるバッファ長の頻度をまとめて、そのような方式でバッファ調律を可能にするためにヒストグラムとして言い表されるかもしれません。 サイズ対パーセントの再命令されたパケットが対応したバッファがあるCDFは有益であるかもしれません。
4.5. Gaps between Multiple Reordering Discontinuities
4.5. 複数のReordering不連続のギャップ
4.5.1. Metric Names
4.5.1. メートル法の名前
Type-P-Packet-Reordering-Gap-Stream Type-P-Packet-Reordering-GapTime-Stream
タイプPパケットReorderingギャップストリーム型PパケットReordering-GapTimeの流れ
4.5.2. Parameters
4.5.2. パラメタ
We use the same parameters defined earlier, but add the convention that index i' is greater than i, likewise j' > j, and define:
'私たちは、そのインデックスiが'i、同様にjよりすばらしい'というコンベンション>jを加えるのを除いて、より早く定義された同じパラメタを使用して、以下を定義します。
+ Gap(s[j']), the Reordering Gap of packet s[j'] in units of integer
messages
'+ ギャップ(s[j'])、ユニットの整数メッセージのパケットsのReordering Gap[j']
and the OPTIONAL parameter:
OPTIONALパラメタ:
+ GapTime(s[j']), the Reordering Gap of packet s[j'] in units of
seconds
'+ GapTime(s[j'])、ユニットの秒のパケットsのReordering Gap[j']
4.5.3. Definition of Reordering Discontinuity
4.5.3. Reordering不連続の定義
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]と定義された再命令不連続におけるパケットに関連づけられます。
Morton, et al. Standards Track [Page 17] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[17ページ]。
Note that s[j] will have been found to cause a sequence discontinuity, where s > NextExp when evaluated with the reordered singleton metric as described in Section 3.4.
セクション3.4で説明されるように再命令された単独個体がメートル法で評価されるとそのs[j]が系列不連続、どこs>NextExpを引き起こすかために見つけられてしまうだろうことに注意してください。
Recall that i - e = min(j). Subsequent reordered packets may be associated with the same s[j], or with a different discontinuity. This fact is used in the definition of the Reordering Gap, below.
そのiを思い出してください--e=分(j)。 その後の再命令されたパケットは同じs[j]、または異なった不連続に関連しているかもしれません。 この事実は以下のReordering Gapの定義に使用されます。
4.5.4. Definition of Reordering Gap
4.5.4. Reorderingギャップの定義
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パケットReorderingギャップの流れのメートル法の案配aはGapのために絶え間なさ(そして、GapTime(s[j'])、報告されたいつの間の値)(s[j'])を(すべて)のパケットに評価するか。
If:
:
the packet s[j'] is found to be a reordering discontinuity, based
on the arrival of reordered packet s[i'] with extent e', and
's[j']が再命令不連続になるように見つけられるパケット範囲eで再命令されたパケットs[i']の到着に基づいて、
an earlier reordering discontinuity s[j], based on the arrival of
reordered packet s[i] with extent e was already detected, and
そしてeが既に検出されたという範囲がある再命令されたパケットs[i]の到着に基づく以前の再命令している不連続s[j]。
i' > i, and
そして'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:
'次に、Reordering Gapはパケットs[j']が到着の違いであるので、以下に示されるように再命令不連続を置きます:
Gap(s[j']) = (j') - (j)
'ギャップ(s[j'])が(j')と等しい、-(j)
Gaps MAY also be expressed in time:
また、ギャップは時間内に、言い表されるかもしれません:
GapTime(s[j']) = DstTime(j') - DstTime(j)
'GapTime(s[j'])=DstTime(j')--DstTime(j)
Otherwise:
そうでなければ:
Gap(s[j']) (and GapTime(s[j']) ) for packet s[j'] is 0.
'パケットs[j']のためのギャップ(s[j'])(そして、GapTime(s[j']))は0です。
4.5.5. Discussion
4.5.5. 議論
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
また、別々の再命令不連続を区別できるとき、カウントは報告されるかもしれません(彼らのその不連続、範囲、およびオフセットに関連している再命令されたパケットの数などの不連続記述と共に)。 aのギャップ
Morton, et al. Standards Track [Page 18] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[18ページ]。
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.
Gapメートル法、それらの原因で不連続を再命令する頻度を関連させるのを助けるかもしれません。 受信機デザイナーにとって、また、不連続を再命令する期間を明らかにして、ギャップ長も有益です。 ギャップと範囲を再命令する組み合わせは、受信機が重なるのに関するケースを扱わなければならないかどうかがパケットを再命令したのを明らかにします。
4.6. Reordering-Free Runs
4.6. 無Reorderingの走行
This section defines a metric based on a count of consecutive in-order packets between reordered packets.
このセクションは再命令されることの間のオーダーにおける連続したパケットのカウントに基づいたメートル法のパケットを定義します。
4.6.1. Metric Names
4.6.1. メートル法の名前
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
なし経営のなし経営のなし経営のタイプのパケットReorderingなし経営のa accpktsのPパケットReordering x-numrunsストリーム型PパケットReordering q-squrunsストリーム型PパケットReordering p-numpktsストリーム型P流れ
4.6.2. Parameters
4.6.2. パラメタ
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、下痢の正方形の合計は重要でした。
4.6.3. Definition
4.6.3. 定義
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:
サンプルのパケットが目的地に到着するとき、再命令されたパケットの間のコネオーダーパケットのカウントはReordering-フリーランです。 この定義に従って最小のランレングスがゼロであることに注意してください。 中間コードの例は従います:
r = 0; /* r is the run counter */ x = 0; /* x is the number of runs */ a = 0; /* a is the accumulator of in-order packets */ p = 0; /* p is the number of packets */
r=0。 /*rは走行カウンタ*/x=0です。 /*xは走行*/a=0の数です。 /*aはオーダーにおけるパケット*/p=0のアキュムレータです。 /*pはパケット*/の数です。
Morton, et al. Standards Track [Page 19] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[19ページ]。
q = 0; /* q is the sum of the squares of the runs counted */
q=0。 /*qによる下痢の正方形の合計が*/を数えたということです。
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++;
}
ゆったり過ごします(パケットは一連番号sと共に到着します)。p++; (s>はNextExpと等しいです)/*sがそうなら中で*/を命令してください、そして、r++; a++; /*sはほかの再命令された*/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
平均したReordering-フリーランの長さは/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カウンタは、平均から1対q/1/x(q/a)/(/x))を比較することによって、Reordering-フリーランの変化のしるしを与えます。
4.6.4. Discussion and Illustration
4.6.4. 議論とイラスト
Type-P-packet-Reordering-Free-Run-Stream parameters give a brief summary of the stream's reordering characteristics including the average reordering-free run length, and the variation of run lengths; therefore, a key application of this metric is network evaluation.
タイプのPパケットのReorderingの無料の走行の流れのパラメタは平均した無再命令のランレングスを含む特性を再命令する流れのものの簡潔な概要、およびランレングスの変化をします。 したがって、これほどメートル法の主要なアプリケーションはネットワーク評価です。
For 36 packets with 3 runs of 11 in-order packets, we have:
オーダーにおける11のパケットの3つの走行がある36のパケットに関しては、私たちには、以下があります。
p = 36
x = 3
a = 33
q = 3 * (11*11) = 363
ave. reordering-free run = 11
q/a = 11
(q/a)/(a/x) = 1.0
p=36x=3a=33q=3*(11*11)=363無ave. reorderingの走行=11q/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つの走行、長さ31の1、および1つの長さの2つの走行がある36のパケットに関しては、私たちには、以下があります。
Morton, et al. Standards Track [Page 20] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[20ページ]。
p = 36
x = 3
a = 33
q = 1 + 1 + 961 = 963
ave. reordering-free run = 11
q/a = 29.18
(q/a)/(a/x) = 2.65
p=36x=3a=33q=1+1+961 = 963無ave. reorderingの走行=11q/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は同じ長さです)。
5. Metrics Focused on Receiver Assessment: A TCP-Relevant Metric
5. 測定基準は受信機査定に焦点を合わせました: TCP関連する、メートル法
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].
このセクションはメートル法でaについて説明します。それは再命令するというTCPへの効果に関連していた状態で情報を伝達します。 しかしながら、TCP性能に関して何でも推論するために、テストの流れは興味があるTCP送付者に酷似に堪えなければなりません。 [RFC3148]は指定しなければならない輻輳制御アルゴリズムの特定の局面を記載します。 さらに、RFC3148は、3つのケースのパケット再命令(セクション3.3における)を区別するためにBulk Transfer Capacity測定基準SHOULDには器具があることを勧めます。 上で定義されたサンプル測定基準はわずかかはなはだしく故障しているパケットを分類するという要件を満たします。 このセクションのメートル法は、Fast Retransmitアルゴリズムが呼び出されることを引き起こしながら再命令するか否かに関係なく、見積もる能力でDUP-ACK敷居を超えるかもしれないと言い足します。 追加TCP Kernel Instrumentsは[Mat03]にまとめられます。
5.1. Metric Name
5.1. メートル法の名前
Type-P-Packet-n-Reordering-Stream
タイプPパケットn-Reorderingの流れ
5.2. Parameter Notation
5.2. パラメタ記法
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が送られたパケット(サンプルサイズ)の数と等しい正の整数であることをさせてください。 パケットが送ったkから受け取られたパケットの数を表して、lが非負の整数であることをさせてください。 (kとlとの関係が全くないことに注意してください: 一方では、損失はkよりlを作ることができません; 他方では、写しで、lはk.よりすばらしくなる場合があります) パケット放出の順に一連番号、kへの1をそれぞれの送られたパケットに割り当ててください。
Let s[1], s[2], ..., s[l] be the original sequence numbers of the received packets, in the order of arrival.
s[1]、s[2]、…をさせてください。, s[l]、到着の注文における、容認されたパケットの元の一連番号になってください。
Morton, et al. Standards Track [Page 21] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[21ページ]。
5.3. Definitions
5.3. 定義
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<、ソース一連番号s[i]でi<=l)がn-reorderedである、そのようなすべてのj jそのi-n<=<i(s[j]>s[i])のために単に
Claim: If, by this definition, a packet is n-reordered and 0 < n' < n, then the packet is also n'-reordered.
以下を要求してください。 'この定義でパケットがn-reorderedと0<n'<nであるなら、また、パケットは再命令されたn'です。
Note: This definition is illustrated by C code in Appendix A. The code determines and reports the n-reordering for n from 1 to a specified parameter (MAXN in the code, set to 100). The value of n conjectured to be relevant for TCP is the TCP duplicate ACK threshold (set to the value of 3 by paragraph 2 of Section 3.2 of [RFC 2581]).
以下に注意してください。 この定義は、コードが決定するAppendix A.でCコードによって例証されて、1〜指定されたパラメタ(100に設定されたコードのMAXN)までのnのためにn-reorderingを報告します。 TCPにおいて関連しているように推測されたnの値はTCP写しACK敷居(3の値に、[RFC2581]のセクション3.2のパラグラフ2でセットする)です。
This definition does not assign an n to all reordered packets as
defined by the singleton metric, in particular when blocks of
successive packets are reordered. (In the arrival sequence
s={1,2,3,7,8,9,4,5,6}, packets 4, 5, and 6 are reordered, but only
packet 4 is n-reordered, with n=3.)
この定義はブロックの連続したパケットが再命令されるとき、特定のメートル法の単独個体によって定義されるようにすべての再命令されたパケットにnを割り当てません。 (1、2、3、7、8、9、4、5、到着順s=6では、パケット4、5、および6は再命令されますが、唯一のパケット4はn=3とn-reorderedです。)
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-reorderingの度はm/lです。(そこでは、mがサンプルのn-reorderedパケットの数です)。
Definition 3: The degree of monotonic reordering of a sample is its degree of 1-reordering.
定義3: サンプルの単調な再命令の度はその1-reorderingの学位です。
Definition 4: A sample is said to have no reordering if its degree of monotonic reordering is 0.
定義4: サンプルは単調な再命令の学位が0であるなら再命令でないのを持っていると言われます。
Note: As follows from the claim above, if monotonic reordering of a sample is 0, then the n-reordering of the sample is 0 for all n.
以下に注意してください。 以下の通り、クレームから、サンプルの単調な再命令が0であるなら、サンプルのn-reorderingはすべてのnのための上では、0です。
5.4. Discussion
5.4. 議論
The degree of n-reordering may be expressed as a percentage, in which case the number from Definition 2 is multiplied by 100.
n-reorderingの度は割合として表されるかもしれません、その場合、100がDefinition2からの数に掛けられます。
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-reorderingメートル法、写しACK敷居設定に与えられた経路に合っているのにおいて、役立っています。 例えば、経路が5-reorderingほど展示会に出品されないなら、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-reorderingの不在は、受信機が見る一連番号が前の到着パケットに関して単調に増加していることを意味します。
Morton, et al. Standards Track [Page 22] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[22ページ]。
- 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-reorderingの例に対応して1つのパケットを再送して、したがって、輻輳制御の目的のために失われたこのパケットを考えるでしょう(送付者は混雑ウィンドウを半分にするでしょう、と[RFC2581]は見ます)。 3はStream Control Transportプロトコル(SCTP)[RFC2960]のためのデフォルト敷居であり、データグラムCongestion Controlプロトコル(DCCP)[RFC4340]はCongestion Control ID2と共に使用されるいつです: TCPのような輻輳制御[RFC4341]。
A sample's n-reordering may be expressed as a histogram to summarize the frequency for each value of n.
サンプルのn-reorderingは、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-reorderingの定義が、パケットのはっきりした数がTCP送付者にいくつかの状況で不必要に再送されたと予測できないことに注意します、密接に区切られた再命令された単独個体があるケースなどのように。 時間と位置の両方が送付者の振舞いに影響を及ぼします。
A packet's n-reordering designation is sometimes equal to its reordering extent, e. n-reordering is different in the following ways:
パケットのn-reordering名称が時々範囲を再命令するのと等しい、e.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. 範囲、eを持つ以外に、Reorderedパケット(タイプ-P-Reordered=TRUE)はn-reorderedでないかもしれません(例を見てください)。
6. Measurement and Implementation Issues
6. 測定と導入問題
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.
このメモで定義された測定基準によると、アプリケーションのための再命令を測って、それは興味深いアプリケーションと同じ送付パターンを使用するRECOMMENDEDです。 どのような場合でも、すべての流れのパラメタを含む測定結果でパケット世代の正確な方法を報告しなければなりません。
+ To make inferences about applications that use TCP, it is REQUIRED
to use TCP-like Streams as in [RFC3148]
+ 同じくらい中でTCPのようなStreamsを使用するために、TCPを使用してください、それがそうであるアプリケーションに関する推論をREQUIREDにするように[RFC3148]
+ For real-time applications, it is RECOMMENDED to use periodic
streams as in [RFC3432]
+、リアルタイムのアプリケーションのために、それは同じくらい中で周期的な流れを使用するRECOMMENDEDです。[RFC3432]
Morton, et al. Standards Track [Page 23] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[23ページ]。
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.
他のIPPM測定基準がポアソンの流れ[RFC2330]を使用しているセクション3と4の測定基準を報告するのは許容できます。 ポアソンの流れはパケット損失と遅れ測定基準のためにネットワーク性能の「不遍のサンプル」を表します。 しかしながら、ポアソンと共に測定された再命令測定基準を使用する上のアプリケーションカテゴリに関する推論を流れにするのは不正確でしょう。
Test stream designers may prefer to use a periodic sending interval in order to maintain a known temporal bias and allow simplified results analysis (as described in [RFC3432]). In this case, it is RECOMMENDED that the periodic sending interval be chosen to reproduce the closest source packet spacing expected. Testers must recognize that streams sent at the link speed serialization limit MUST have limited duration and MUST consider packet loss an indication that the stream has caused congestion, and suspend further testing.
テスト流れのデザイナーは、知られている時の偏見を維持して、簡易型の結果に分析を許す([RFC3432]で説明されるように)ために周期的な送付間隔を費やすのを好むかもしれません。 この場合、周期的な送付間隔が予想される中で最も近いソースパケットスペースを再生させるために選ばれているのは、RECOMMENDEDです。 テスターは、リンク速度連載限界のときに送られた小川が、持続時間を制限したに違いなくて、パケット損失が流れが混雑を引き起こしたという指示であると考えなければならないと認めて、追加検査を中断させなければなりません。
When intending to compare independent measurements of reordering, it is RECOMMENDED to use the same test stream parameters in each measurement system.
再命令の独立している測定を比較するつもりであるとき、それはそれぞれの測定システムで同じテスト流れのパラメタを使用するRECOMMENDEDです。
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. ロールオーバーが起こったなら、検出するテストがあるに違いありません。 これらの大きい不連続がロールオーバーとして指定されて、連続したパケットの一連番号が全範囲の半分以上でジャンプするのは、ほとんど不可能でしょう。
Morton, et al. Standards Track [Page 24] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[24ページ]。
2. All sequence numbers used in computations are represented in a
sufficiently large precision. The numbers have a correction
applied (equivalent to adding a significant digit) whenever
rollover is detected.
2. 計算に使用されるすべての一連番号が十分大きい精度で表されます。 数で、ロールオーバーが検出されるときはいつも、修正を適用します(有効数字を加えるのに同等な)。
3. Reordered packets coincident with sequence numbers reaching end-
of-range must also be detected for proper application of
correction factor.
3. また、修正率の正当な適用のために一連番号が範囲の端に達しているReorderedパケットコインシデンスを検出しなければなりません。
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.
他の解決法はパケットの滑っている歴史ウィンドウを使用することです。そこでは、ウィンドウサイズが役に立つ再命令範囲で上限で決定するでしょう。 意図している分析によって、これはいくつかのパケットか数秒がパケットの価値であったかもしれないなら付きました。 窓を超えたすべての流れの情報を捨てるとき、再命令している不連続情報が捨てられて、Gap計算が可能でないなら、n-reorderingの再命令範囲か度が、窓の長さよりすばらしいとして言い表される必要があるかもしれません。
The requirement to ignore duplicate packets also mandates storage. Here, tracking the sequence numbers of missing packets may minimize storage size. Missing packets may eventually be declared lost or be reordered if they arrive. The missing packet list and the largest sequence number received thus far (NextExp - 1) are sufficient information to determine if a packet is a duplicate (assuming a manageable storage size for packets that are missing due to loss).
また、写しパケットを無視するという要件は格納を強制します。 ここで、なくなったパケットの一連番号を追跡すると、格納サイズは最小にされるかもしれません。 到着するなら、なくなったパケットは、結局、無くなると宣言されるか、または再命令されるかもしれません。 パケットが写し(損失のためになくなったパケットのために処理しやすい格納サイズを仮定する)であるなら、なくなったパケットリストとこれまでのところ受け取られた中で最も大きい一連番号(NextExp--1)は決定する十分な情報です。
It is important to note that practical IP networks also have limited ability to "store" packets, even when routing loops appear temporarily. Therefore, the maximum storage for reordering metrics (and their complexity) would only approach the number packets in the sample, K, when the sending time for K packets is small with respect to the network's largest possible transfer time. Another possible limitation on storage is the maximum length of the sequence number field, assuming that most test streams do not exhaust this length in practice.
実用的なIPネットワークもパケットを「格納する」能力を制限したことに注意するのは重要です、ルーティング輪が一時現れると。 したがって、測定基準(そして、それらの複雑さ)を再命令するための最大の格納はサンプルで数のパケットにアプローチするだけでしょう、K、Kパケットのための送付時間がネットワークの可能な限り大きい転送時間に関して小さいときに。 格納の別の可能な制限は一連番号分野の最大の長さです、この長さが実際にはほとんどのテストの流れでくたくたにならないと仮定して。
Last, we note that determining reordering extents and gaps is tricky when there are overlapped or nested events. Test instrument complexity and reordering complexity are directly correlated.
最後に、私たちは、重ね合わせられたか入れ子にされた出来事があるとき、範囲を再命令して、ギャップを決定するのが扱いにくいことに注意します。 試験計器の複雑さと複雑さを再命令するのは直接関連します。
Morton, et al. Standards Track [Page 25] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[25ページ]。
6.1. Passive Measurement Considerations
6.1. 受け身の測定問題
As with other IPPM metrics, the definitions have been constructed primarily for Active measurements.
他のIPPM測定基準のように、定義は主としてActive測定値のために構成されました。
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]を避けるのを助けます。
7. Examples of Arrival Order Evaluation
7. 到着オーダー評価に関する例
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-reorderingが比較、および時間、バイト、および位置のすべての寸法における再命令を定量化する値でどう働いているか。
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到着指数を決定するために各例のテーブルを参照するべきです、必要であるなら」。
7.1. Example with a Single Packet Reordered
7.1. 独身のパケットReorderedがある例
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は再命令の簡単なケースを与えます。Packet4、そこでは、1つのパケットが再命令されます。 彼らの到着に従って、パケットは記載されています、そして、メッセージ付番は使用されています。 すべてのパケットがs=1であることのSrcByte=(s x100)-99、2、3、4、…に従ったPayloadSize=100バイトを含んでいます。
Morton, et al. Standards Track [Page 26] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[26ページ]。
Table 1: Example with Packet 4 Reordered, Sending order( s @Src): 1,2,3,4,5,6,7,8,9,10
テーブル1: Packet4Reorderedがある例、Sendingオーダー(s@Src): 1,2,3,4,5,6,7,8,9,10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
5 4 80 148 68 -82 4
6 6 100 168 68 0 5
7 7 120 188 68 0 6
8 8 140 208 68 0 7
4 9 60 210 150 82 8 400 62
9 9 160 228 68 0 9
10 10 180 248 68 0 10
s Src Dst Dstバイト@Dst NextExp時間時間遅れIPDVオーダー時間遅くオフセット----------------------------------------------------------------- 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 Packetタイムスタンプ、目的地の原稿DstTime Packetタイムスタンプ、パケットの原稿Delay1ウェイ遅れ、原稿IPDV IP Packet Delay Variation、ms IPDVはパケットが目的地に到着した遅れ(SrcNum)遅れ(SrcNum-1)DstOrder Orderと等しいです。 バイトが相殺したバイトで表現される再命令されたパケットのバイトOffset。 LateTimeは原稿で、再命令されたパケットの遅れです。
We can see that when Packet 4 arrives, NextExp=9, and it is declared reordered. We compute the extent of reordering as follows:
NextExp=9、Packet4が到着して、それが再命令されていると宣言されるとき、私たちはそれを見ることができます。 私たちは以下の通り再命令する範囲を計算します:
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
/\
=1、2、3、5、6、7、8、4、9、10i=1、2、3、4、5、6、7、8、9、10\/s/\
Applying the definition of Type-P-Packet-Reordering-Extent-Stream:
Type-PパケットReordering範囲の流れの定義を適用します:
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以上です。
Morton, et al. Standards Track [Page 27] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[27ページ]。
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.
さらに、Packet5の到着と比べて、私たちはLate Time(210-148=62 DstTimeを使用するms)を計算できます。 受信機に4つ以上のパケット、または少なくとも62ms格納を保持する反-ジターバッファがあるなら、Packet4は役に立つかもしれません。 1ウェイ遅れとIPDVがPacket4のために異常挙動を示すことに注意してください。 また、Packet4が到着したなら、少なくともより早くそれが持っている62msもこの例で中で注文しています。
If all packets contained 100 byte payloads, then Byte Offset is equal to 400 bytes.
すべてのパケットが100バイトのペイロードを含んだなら、Byte Offsetは400バイトと等しいです。
Following the definitions of Section 5.1, Packet 4 is designated 4-reordered.
セクション5.1の定義に続いて、Packet4は4-reorderedに指定されます。
7.2. Example with Two Packets Reordered
7.2. 2パケットReorderedがある例
Table 2 Example with Packets 5 and 6 Reordered, Sending order(s @Src): 1,2,3,4,5,6,7,8,9,10
テーブル2 Packets5と6ReorderedとExample、Sendingオーダー(s@Src): 1,2,3,4,5,6,7,8,9,10
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
4 4 60 128 68 0 4
7 5 120 188 68 -22 5
5 8 80 189 109 41 6 100 1
6 8 100 190 90 -19 7 100 2
8 8 140 208 68 0 8
9 9 160 228 68 0 9
10 10 180 248 68 0 10
s Src Dst Dstバイト@Dst NextExp時間時間遅れIPDVオーダー時間遅くオフセット----------------------------------------------------------------- 1 1 0 68 68 1 2 2 20 88 68 0 2 3 3 40 108 68 0 3 4 4 60 128 68 0 4 7 5 120 188 68 -22 5 5 8 80 189 109 41 6 100 1 6 8 100 190 90 -19 7 100 2 8 8 140 208 68 0 8 9 9 160 228 68 0 9 10 10 180 248 68 0 10
Table 2 shows a case where Packets 5 and 6 arrive just behind Packet 7, so both 5 and 6 are reordered. The Late times (189-188=1, 190-188=2) are small.
テーブル2が、Packets5と6がPacket7直後でどこに到着するかをケースに示すので、5と両方6は再命令されます。 Late回(190-188=2の189-188=1)は小さいです。
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
/\ /\
1、2、3、4、7、5、6、8、9、=10\/\/s i=1、2、3、4、5、6、7、8、9、10/\/円
Morton, et al. Standards Track [Page 28] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[28ページ]。
Considering Packet 5 first:
考慮Packet5 1番目:
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、1が最大の範囲であり私たちがいつ4<5を持つか、そして、e=1であるときに。
Considering Packet 6 next:
次の考慮Packet6:
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(両方のパケットのための)を見つけます。 それで、Packet6はPacket7でPacket5、Reordering Discontinuityとして不連続を再命令する同じくらいに関連しています。
This is a case where reordering extent e would over-estimate the packet storage required to restore order. Only one packet storage is required (to hold Packet 7), but e=2 for Packet 6.
これはeがパケット格納を過大評価するだろうという範囲を再命令するのが秩序を回復するのが必要であるそうです。 1つのパケットだけの格納が必要であり(Packet7を持つ)、Packetのための唯一のe=2は6です。
Following the definitions of Section 5, Packet 5 is designated 1-reordered, but Packet 6 is not designated n-reordered.
セクション5の定義に続いて、Packet5は1-reorderedに指定されますが、Packet6は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-reordered(単独個体に合意したメートル法の)であるので、不必要にPacket5を再送するかもしれません。 Packet6は不必要に再送されないかもしれませんが、Packet6が到着した後まで受信機はPacket7をより高い層に進めることができません。 したがって、単独個体、メートル法、Packet6が再命令されると正しく決心しています。
Morton, et al. Standards Track [Page 29] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[29ページ]。
7.3. Example with Three Packets Reordered
7.3. 3パケットReorderedがある例
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 Packets4、5、および6reordered SendingとExampleは(s@Src)を命令します: 1,2,3,4,5,6,7,8,9,10,11
s Src Dst Dst Byte Late
@Dst NextExp Time Time Delay IPDV Order Offset Time
-----------------------------------------------------------------
1 1 0 68 68 1
2 2 20 88 68 0 2
3 3 40 108 68 0 3
7 4 120 188 68 -88 4
8 8 140 208 68 0 5
9 9 160 228 68 0 6
10 10 180 248 68 0 7
4 11 60 250 190 122 8 400 62
5 11 80 252 172 -18 9 400 64
6 11 100 256 156 -16 10 400 68
11 11 200 268 68 0 11
s Src Dst Dstバイト@Dst NextExp時間時間遅れIPDVオーダー時間遅くオフセット----------------------------------------------------------------- 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.
Table3のケースは3つのパケットが連続して、長いトランジット時(s=4、5、および6があるパケット)を過すところです。 遅れ、Late時間、およびByte Offsetはこれを非常によく捕らえて、範囲を再命令することの変化を示します、IPDVは、パケット4、5、および6の間のスペースが変化したのを示しますが。
The histogram of Reordering extents (e) would be:
Reordering範囲(e)のヒストグラムは以下の通りでしょう。
Bin 1 2 3 4 5 6 7 Frequency 0 0 0 1 1 1 0
容器1 2 3 4 5 6 7頻度0 0 0 1 1 1 0
Using the notation <s[1], ..., s[i], ..., s[l]>, the received packets are represented as:
記法<s[1]を使用します…, s[i]…, s[l]>、容認されたパケットは以下として表されます。
s = 1, 2, 3, 7, 8, 9,10, 4, 5, 6, 11 i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,11
s=1、2、3、7、8、9、10、4、5、6、11i=1、2、3、4、5、6、7、8、9、10、11
We first calculate the n-reordering. Considering Packet 4 first:
私たちは最初に、n-reorderingについて計算します。 考慮Packet4 1番目:
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-reorderedです。n=2であるときに、6<がj<8、および9>4と等しいので、パケットは2-reorderedです。n=3であるときに、5<がj<8、および8>4と等しいので、パケットは3-reorderedです。n=4であるときに、4<がj<8、および7>4と等しいので、パケットは4-reorderedです。n=5であるときに、j<8にもかかわらず、3 3<=<4、および4は最大のn-reorderingです。
Morton, et al. Standards Track [Page 30] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[30ページ]。
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-reorderedとして指定されません。 私たちはPacket6に関して同じ結果を見つけます。
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.
私たちは、現在、reordered Packets5と6がPacket4として不連続を再命令する同じくらいに関連しているかどうか考えます。 セクション4.2.3のテストを使用して、私たちは、すべての3つのパケットのためにそれが最小のj=4であることがわかりました。 それらはPacket7の再命令不連続にすべて関連しています。
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-reordering定義がNewリノTCP送付者(3かDUP-ACK敷居=4がある)で1個の不要なパケット「再-トランスミッション」を引き起こすかもしれないn-reorderingの十分な程度と独身のPacket(4)を同一視するのを再び示します。 また、Packets5と6の再命令された到着で、受信機の過程はプロトコル・スタックでPackets7〜10を渡すことができるでしょう(単独個体Type-P-ReorderedがPackets5と6のためにTRUEと等しいです、そして、彼らは皆、不連続を再命令するシングルに関連しています)。
7.4. Example with Multiple Packet Reordering Discontinuities
7.4. 複数のパケットReordering不連続がある例
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 Multiple Packet Reordering Discontinuities SendingとExampleは(s@Src)を命令します: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
Discontinuity Discontinuity
|---------Gap---------|
s = 1, 2, 3, 6, 7, 4, 5, 8, 9, 10, 12, 13, 11, 14, 15, 16
i = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
不連続不連続|---------ギャップ---------| s=1、2、3、6、7、4、5、8、9、10、12、13、11、14、15、16i=1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16
r = 1, 2, 3, 4, 5, 0, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, ... number of runs,n = 1 2 3 end r counts = 5 0 5 (These values are computed after the packet arrives.)
… r=1、2、3、4、5、0、0、1、2、3、4、5、0、1、2、3、走行の数、n=1 2 3終わりrのカウントは5 0 5と等しいです。(パケットが到着した後にこれらの値は計算されます。)
Packet 4 has extent e=2, Packet 5 has extent e=3, and Packet 11 has e=2. There are two different reordering discontinuities, one at Packet 6 (where j=4) and one at Packet 12 (where j'=11).
パケット4には範囲e=2があります、そして、Packet5には範囲e=3があります、そして、Packet11には、e=2があります。 'そこでは、2が、不連続、Packet6の1(どこj=4)、およびPacket12の1つ(j'が11と等しいところ)を再命令するかながら、異なっていますか?
According to the definition of Reordering Gap Gap(s[j']) = (j') - (j) Gap(Packet 12) = (11) - (4) = 7
'Reordering Gap Gapの定義に従って、(s[j'])は(j')--(j) ギャップ(パケット12)=(11)--(4) =7と等しいです。
We also have three reordering-free runs of lengths 5, 0, and 5.
また、私たちには、長さ5、0、および5の3つの無再命令の走行があります。
The differences between these two multiple-event metrics are evident here. Gaps are the distance between sequence discontinuities that are subsequently defined as reordering discontinuities, while reordering-free runs capture the distance between reordered packets.
これらの2つの複数のイベント測定基準の違いはここで明白です。 ギャップは次に不連続を再命令すると定義される系列不連続の間の距離です、無再命令の走行が再命令されたパケットの間の距離を得ますが。
Morton, et al. Standards Track [Page 31] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[31ページ]。
8. Security Considerations
8. セキュリティ問題
8.1. Denial-of-Service Attacks
8.1. サービス不能攻撃
This metric requires a stream of packets sent from one host (source) to another host (destination) through intervening networks. This method could be abused for denial-of-service attacks directed at destination and/or the intervening network(s).
これほどメートル法、介入しているネットワークを通して1人のホスト(ソース)から別のホスト(目的地)に送られたパケットの流れを必要とします。 目的地が向けられたサービス不能攻撃、そして/または、介入しているネットワークのためにこの方法を乱用できました。
Administrators of the source, destination, and intervening network(s) should establish bilateral or multilateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed between the participants may be cause for immediate rejection or discard of packets or other escalation procedures defined between the affected parties.
ソース、目的地、および介入しているネットワークの管理者はサンプル測定基準の収集のタイミング、サイズ、および頻度に関する双方の、または、多面的な協定を確立するべきです。 関係者の間で同意される諸条件を超えたこの方法の使用は、パケットの即座の拒絶か破棄の原因か影響を受けた当事者の間で定義された他の増大手順であるかもしれません。
8.2. User Data Confidentiality
8.2. 利用者データ秘密性
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.
この方法の能動的使用は、サンプルのために利用者データに基づいて見本を作るよりパケットをむしろ発生させて、ユーザデータの機密性を脅かしません。 受け身の測定は興味があるヘッダーへの注意を制限しなければなりません。 ユーザペイロードが長さの分析のために一時格納されるかもしれないので、この情報を安全で秘密に保つために適当な注意を払わなければなりません。 多くの場合、論じ尽くす機能はペイロード比較に適した値を生産するでしょう。
8.3. Interference with the Metric
8.3. メートル法の干渉
It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g., increasing or decreasing delay) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement. The likely consequences of packet injection are that the additional packets would be declared duplicates, or that the original packets would be seen as duplicates (if they arrive after the corresponding injected packets), causing invalid measurements on the injected packets.
パケットのあるパケットか流れがサンプルの一部であることを特定するのは可能であるかもしれません。 目的地のその知識、そして/または、介入しているネットワークでは、測定性能を歪めるかもしれないパケット(例えば、増加するか減少している遅れ)の処理を変えるのは可能です。 また、メートル法でサンプルの一部であるように見える追加パケットを発生させるのも可能であるかもしれません。 これらの追加パケットはサンプル測定の結果を混乱させそうです。 パケット注射の起こりそうな結果は追加パケットが写しであると宣言されるだろうか、またはオリジナルのパケットが写しと考えられるだろうという(対応がパケットを注入した後に到着するなら)ことです、注入されたパケットの無効の測定を引き起こして。
The requirements for data collection resistance to interference by malicious parties and mechanisms to achieve such resistance are available in other IPPM memos. A set of requirements for a data collection protocol can be found in [RFC3763], and a protocol specification for the One-Way Active Measurement Protocol (OWAMP) is
悪意があるパーティーとメカニズムによる干渉へのデータ収集抵抗がそのような抵抗を実現するという要件は他のIPPMメモで利用可能です。 [RFC3763]、およびプロトコル仕様でActive Measurementプロトコル(OWAMP)があるOne-方法に関してデータ収集プロトコルのための1セットの要件を見つけることができます。
Morton, et al. Standards Track [Page 32] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[32ページ]。
in [RFC4656]. The security considerations sections of the two OWAMP documents are extensive and should be consulted for additional details.
[RFC4656]で。 2通のOWAMPドキュメントのセキュリティ問題部は、大規模であり、追加詳細のために相談されるべきです。
9. IANA Considerations
9. IANA問題
Metrics defined in this memo have been registered in the IANA IPPM METRICS REGISTRY as described in initial version of the registry [RFC4148].
登録[RFC4148]の初期のバージョンで説明されるようにIANA IPPM METRICS REGISTRYにこのメモで定義された測定基準を登録してあります。
IANA has registered the following metrics in the IANA-IPPM-METRICS- REGISTRY-MIB:
IANAはIANA-IPPM-METRICS- REGISTRY-MIBでの以下の測定基準を登録しました:
ietfReorderedSingleton OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Reordered"
REFERENCE
"Reference RFC 4737, Section 3"
::= { ianaIppmMetrics 34 }
ietfReorderedSingleton OBJECT-IDENTITY STATUSの現在の記述「タイプ-P-Reordered」REFERENCE、「以下にRFC4737、セクション3インチ参照をつけてください」= ianaIppmMetrics34
ietfReorderedPacketRatio OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Reordered-Ratio-Stream"
REFERENCE
"Reference RFC 4737, Section 4.1"
::= { ianaIppmMetrics 35 }
ietfReorderedPacketRatio OBJECT-IDENTITY STATUSの現在の記述「タイプP-Reordered比率の流れ」REFERENCE、「以下にRFC4737、セクション4.1インチ参照をつけてください」= ianaIppmMetrics35
ietfReorderingExtent OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Extent-Stream"
REFERENCE
"Reference RFC 4737, Section 4.2"
::= { ianaIppmMetrics 36 }
現在のietfReorderingExtent OBJECT-IDENTITY STATUSの記述「タイプPパケットReordering範囲の流れ」REFERENCE、「以下にRFC4737、セクション4.2インチ参照をつけてください」= ianaIppmMetrics36
ietfReorderingLateTimeOffset OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Late-Time-Stream"
REFERENCE
"Reference RFC 4737, Section 4.3"
::= { ianaIppmMetrics 37 }
現在のietfReorderingLateTimeOffset OBJECT-IDENTITY STATUSの記述「タイプのPパケットの遅い時間の流れ」REFERENCE、「以下にRFC4737、セクション4.3インチ参照をつけてください」= ianaIppmMetrics37
ietfReorderingByteOffset OBJECT-IDENTITY
STATUS current
DESCRIPTION
ietfReorderingByteOffset OBJECT-IDENTITY STATUSの現在の記述
Morton, et al. Standards Track [Page 33] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[33ページ]。
"Type-P-Packet-Byte-Offset-Stream"
REFERENCE
"Reference RFC 4737, Section 4.4"
::= { ianaIppmMetrics 38 }
「以下にRFC4737、セクション4.4インチ参照をつけてください」という「タイプPパケットバイトオフセット・ストリーム」参照= ianaIppmMetrics38
ietfReorderingGap OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Gap-Stream"
REFERENCE
"Reference RFC 4737, Section 4.5"
::= { ianaIppmMetrics 39 }
現在のietfReorderingGap OBJECT-IDENTITY STATUSの記述「タイプPパケットReorderingギャップの流れ」REFERENCE、「以下にRFC4737、セクション4.5インチ参照をつけてください」= ianaIppmMetrics39
ietfReorderingGapTime OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-GapTime-Stream"
REFERENCE
"Reference RFC 4737, Section 4.5"
::= { ianaIppmMetrics 40 }
現在のietfReorderingGapTime OBJECT-IDENTITY STATUSの記述「タイプPパケットReordering-GapTimeの流れ」REFERENCE、「以下にRFC4737、セクション4.5インチ参照をつけてください」= ianaIppmMetrics40
ietfReorderingFreeRunx OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-x-numruns-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 41 }
現在のietfReorderingFreeRunx OBJECT-IDENTITY STATUSの記述「タイプのPパケットのReorderingのなし経営のx-numrunsの流れ」REFERENCE、「以下にRFC4737、セクション4.6インチ参照をつけてください」= ianaIppmMetrics41
ietfReorderingFreeRunq OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-q-squruns-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 42 }
現在のietfReorderingFreeRunq OBJECT-IDENTITY STATUSの記述「タイプのPパケットのReorderingのなし経営のq-squrunsの流れ」REFERENCE、「以下にRFC4737、セクション4.6インチ参照をつけてください」= ianaIppmMetrics42
ietfReorderingFreeRunp OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 43 }
現在のietfReorderingFreeRunp OBJECT-IDENTITY STATUSの記述「タイプのPパケットのReorderingのなし経営のp-numpktsの流れ」REFERENCE、「以下にRFC4737、セクション4.6インチ参照をつけてください」= ianaIppmMetrics43
ietfReorderingFreeRuna OBJECT-IDENTITY
STATUS current
DESCRIPTION
ietfReorderingFreeRuna OBJECT-IDENTITY STATUSの現在の記述
Morton, et al. Standards Track [Page 34] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[34ページ]。
"Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream"
REFERENCE
"Reference RFC 4737, Section 4.6"
::= { ianaIppmMetrics 44 }
「以下にRFC4737、セクション4.6インチ参照をつけてください」という「タイプのパケットのReorderingのなし経営のa accpktsのP流れ」参照= ianaIppmMetrics44
ietfnReordering OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Packet-n-Reordering-Stream"
REFERENCE
"Reference RFC 4737, Section 5"
::= { ianaIppmMetrics 45 }
現在のietfnReordering OBJECT-IDENTITY STATUSの記述「タイプPパケットn-Reorderingの流れ」REFERENCE、「以下にRFC4737、セクション5インチ参照をつけてください」= ianaIppmMetrics45
10. Normative References
10. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
[RFC2330]パクソン(V.とAlmesとG.とMahdavi、J.とM.マシス、「IPパフォーマンス測定基準のための枠組み」RFC2330)は1998がそうするかもしれません。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148, July
2001.
[RFC3148] マシスとM.とM.オールマン、「実証的なバルク転送容量測定基準を定義するための枠組み」、RFC3148、2001年7月。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432,
November 2002.
2002年11月の[RFC3432]RaisanenとV.とGrotefeld、G.とA.モートン、「周期的な流れによるネットワーク性能測定」RFC3432。
[RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active
Measurement Protocol (OWAMP) Requirements", RFC 3763,
April 2004.
[RFC3763] ShalunovとS.とB.タイテルバウム、「片道アクティブな測定プロトコル(OWAMP)要件」、RFC3763、2004年4月。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
[RFC4148] シュテファン、E.、「IPパフォーマンス測定基準(IPPM)測定基準登録」、BCP108、RFC4148、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.、タイテルバウム、B.、カープ、A.、Boote、J.、およびM.Zeckauskas、「A One-道のアクティブな測定プロトコル(OWAMP)」、RFC4656 2006年9月。
Morton, et al. Standards Track [Page 35] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[35ページ]。
11. Informative References
11. 有益な参照
[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.サヴェージ、「測定パケットReordering」、ACM SIGCOMMインターネット測定ワークショップ2002年11月6日-8、マルセイユ、フランスの議事。
[Ben99] J.C.R. Bennett, C. Partridge, and N. Shectman, "Packet
Reordering is Not Pathological Network Behavior," IEEE/ACM
Transactions on Networking, vol. 7, no. 6, pp. 789-798,
December 1999.
[Ben99]J.C.R.ベネット、C.Partridge、およびN.Shectman、「パケットReorderingはNot Pathological Network Behaviorです」、Networkingの上のIEEE/ACM Transactions、vol.7、No.6、ページ 789-798と、1999年12月。
[Cia00] L. Ciavattone and A. Morton, "Out-of-Sequence Packet
Parameter Definition (for Y.1540)", Contribution number
T1A1.3/2000-047, October 30, 2000,
http://home.comcast.net/~acmacm/IDcheck/0A130470.doc.
[Cia00] L.CiavattoneとA.モートン、「順序が狂ってパケットパラメタ定義(Y.1540のための)」、Contribution番号T1A1.3/2000-047、2000年10月30日、 http://home.comcast.net/~acmacm/IDcheck/0A130470.doc 。
[Cia03] L. Ciavattone, A. Morton, and G. Ramachandran,
"Standardized Active Measurements on a Tier 1 IP
Backbone," IEEE Communications Mag., pp. 90-97, June 2003.
[Cia03]L.Ciavattone(A.モートン、およびG.ラマチャンドラン)は「層1のIP背骨に関するアクティブな測定値を標準化しました」、IEEE Communications Mag、ページ 90-97と、2003年6月。
[I.356] ITU-T Recommendation I.356, "B-ISDN ATM layer cell
transfer performance", March 2000.
[I.356]ITU-T Recommendation 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他と、「測定と外の系列の分類パケットコネa層-1IP背骨」、ACM SIGCOMMインターネットMeasurement Workshop2002年11月6日-8つのもののProceedings、マルセイユフランス。
[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と「Low- bitrateインターネットVideo Streamingの測定Study」、H.2001年のACM SIGCOMMインターネットMeasurement Workshop2001年11月1日〜2日のProceedings、サンフランシスコラダ(米国)。
[Mat03] M. Mathis, J. Heffner, and R. Reddy, "Web100: Extended TCP
Instrumentation for Research, Education and Diagnosis",
ACM Computer Communications Review, Vol 33, Num 3, July
2003, http://www.web100.org/docs/mathis03web100.pdf.
[Mat03] M.マシス、J.ヘフナー、およびR.レディ、「Web100:」 「研究、教育、および診断のための拡張TCP計装」、ACMコンピュータコミュニケーションレビュー、Vol33、ヌム3 2003年7月、 http://www.web100.org/docs/mathis03web100.pdf 。
[Pax98] V. Paxson, "Measurements and Analysis of End-to-End
Internet Dynamics," Ph.D. dissertation, U.C. Berkeley,
1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz.
[Pax98]V.パクソンと、「終わりから終わりへのインターネット力学の測定値と分析」、博士号論文、U.C.バークレー、1997、 ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz 。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
Morton, et al. Standards Track [Page 36] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[36ページ]。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control ", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、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における、メートル法のA One-道の遅れ」、RFC2679、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における、メートル法のA One-道のパケット損失」、RFC2680、1999年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC2960] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC3393]デミチェリスとC.とP.Chimento、「IPパフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、2002年11月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006.
[RFC4341] フロイド、S.、およびE.コーラーは「データグラム混雑制御プロトコル(DCCP)輻輳制御ID2のために以下の輪郭を描きます」。 「TCPのような輻輳制御」、RFC4341、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.A.P.Jayasumana、「パケット系列における、Reorderingの学位のための測定基準」、Proc。 2002年11月のローカル・コンピュータ・ネットワーク、タンパ、フロリダの第27IEEEコンファレンス。
[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 Recommendation Y.1540、「インターネットはデータ通信サービスについて議定書の中で述べます--IPパケット転送と有用性性能パラメタ」、12月2002日
12. Acknowledgements
12. 承認
The authors would like to acknowledge many helpful discussions with Matt Zekauskas, Jon Bennett (who authored the sections on Reordering-Free Runs), and Matt Mathis. We thank David Newman, Henk Uijterwaal, Mark Allman, Vern Paxson, and Phil Chimento for their reviews and suggestions, and Michal Przybylski for sharing implementation experiences with us on the ippm-list. Anura Jayasumana and Nischal Piratla brought in recent work-in-progress [TBABAJ02]. We gratefully acknowledge the foundation laid by the authors of the IP performance framework [RFC2330].
作者はマットZekauskas、ジョン・ベネット(自由なReordering Runsの上のセクションを書いた)、およびマット・マシスとの多くの役立つ議論を承諾したがっています。 私たちはippm-リストでデヴィッド・ニューマン、ヘンクUijterwaal、マーク・オールマン、バーン・パクソン、彼らのレビューと提案のためのフィルChimento、および私たちの実現経験を共有するためのミハル・プシビルスキに感謝します。 Anura JayasumanaとNischal Piratlaは最近の進行中の仕事[TBABAJ02]を持って入りました。 私たちは感謝してIP性能枠組み[RFC2330]の作者によって築かれた基礎を承認します。
Morton, et al. Standards Track [Page 37] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[37ページ]。
Appendix A. Example Implementations in C (Informative)
Cでの付録A.例の実現(有益)です。
Two example c-code implementations of reordering definitions follow:
再命令定義の2つの例のc-コード実現が続きます:
Example 1 n-reordering ============================================
例1のn-reordering============================================
#include <stdio.h>
#<stdio.h>を含めてください。
#define MAXN 100
#MAXN100を定義してください。
#define min(a, b) ((a) < (b)? (a): (b)) #define loop(x) ((x) >= 0? x: x + MAXN)
#分(a、b)を定義してください、((a) <(b)?(a): (b)) #輪(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.
*
*/
/**は、新しい一連番号を読んで、それを返します。 それ以上の一連番号が全くないとき、(少なくとも一度)EOFの歩しょう値*を返してください。 * この例では、一連番号はstdinから来ます。 * 実際のテストで、彼らはネットワークから来るでしょう。 * */
int
read_sequence_number()
{
int res, rc;
rc = scanf("%d\n", &res);
if (rc == 1) return res;
else return EOF;
}
intは_系列_数()を読みました。int res、rcに、rcがscanfと等しい、(「%d\n」、およびres) ; (rc=1)であるなら、resを返してください; リターンのEOFほかの
int
main()
{
int m[MAXN]; /* We have m[j-1] == number of
* j-reordered packets. */
int ring[MAXN]; /* Last sequence numbers seen. */
int r = 0; /* Ring pointer for next write. */
int l = 0; /* Number of sequence numbers read. */
int s; /* Last sequence number read. */
int j;
/*は見られた一連番号を持続します。intメイン()、int m[MAXN]; 私たちがm[j-1]=に付番させる*j-reorderedパケット*/intリング[MAXN]の/*; r=0 ; 次に/*リングポインタが最後の一連番号に0; 一連番号読書*/int sの/*数; /*と等しいと. */int lに書く*/intは. */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;
}
(j=0; j<MAXN; j++)m[j]=0のために。 (;(s=は_系列_数())!=EOFを読みました; l(r+1)%+ +、r=MAXN) (j=0、;j<分(l、MAXN)、リング[r]がsと等しいというs<リング[輪(r-j-1]; j++)m[j]++
Morton, et al. Standards Track [Page 38] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[38ページ]。
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);
}
(j=0 ; j<MAXN、m[j]; + +) j printf、(「%d-reordering=%、f%%\n」、j+1、100.0*m[j]/(l-j-1)。 (j=0)printf(「再命令\がありませんn」)であるなら。 ほか、(j<MAXN)printfである、(「%がありませんd-reordering\n」、j+1)、。 ほかのprintf(「単に%まで、d-reorderingは扱われた\nです」、MAXN)。 出口(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
*/
/*例2の単独個体とn-reordering比較======= 以下を書いてください。 ジェリーPerser7-2002(acm12-2004によるモッズ)はコンパイルします: $gcc-o jpboth file.c Usage: カット/ペースタへの$jpboth1 2 3 7 8 4 5 6(cmdlineで与えられたpkt系列)紙幣: 線59は修理*/を必要とするかもしれません。
#include <stdio.h>
#<stdio.h>を含めてください。
#define MAXN 100
#define min(a, b) ((a) < (b)? (a): (b))
#define loop(x) ((x) >= 0? x: x + MAXN)
#定義、MAXN100#、が分(a、b)を定義する、((a) <(b)?(a): (b)) #輪(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)*/
/*グローバルなカウンタ*/intは_パケット=0を受け取ります。 容認された*/int追加注文_パケット_アル=0の/*数。 /*num reordered pkts(単独個体)*/int追加注文_パケット_スタース=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;
現在のパケットがあったならテストする/*機能がどんな再命令された*1=再命令された*/int testorder1(int seqnum)//*リターン0=アルも再命令しなかった、静的なint NextExp=1(int iReturn=0)
if (seqnum >= NextExp) {
NextExp = seqnum+1;
} else {
iReturn = 1;
}
return iReturn;
}
(seqnum>=NextExp)である、NextExp=seqnum+1;、ほか、iReturn=1; iReturnを返してください。 }
int testorder2(int seqnum) // Stanislav
{
static int ring[MAXN]; /* Last sequence numbers seen. */
static int r = 0; /* Ring pointer for next write */
静的なintリング[MAXN]; /*は見られた一連番号を持続します。int testorder2(int seqnum)//スタニスラフ、*/静的なint rは次のための*リングポインタが*/を書く0;/と等しいです。
Morton, et al. Standards Track [Page 39] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[39ページ]。
int l = 0; /* Number of sequence numbers read. */
int j;
int iReturn = 0;
int l=0。 一連番号の/*数は読みます。 */int j。 int iReturn=0。
l++;
r = (r+1) % MAXN;
for (j=0; j<min(l, MAXN) && seqnum<ring[loop(r-j-1)]; j++)
iReturn = 1;
ring[r] = seqnum;
return iReturn;
}
int main(int argc, char *argv[])
{
int i, packet;
for (i=1; i< argc; i++) {
receive_packets++;
packet = atoi(argv[i]);
reorder_packets_Al += testorder1(packet); // singleton
reorder_packets_Stas += testorder2(packet); //n-reord.
}
printf("Received packets = %d, Singleton Reordered = %d, n-
reordered = %d\n", receive_packets, reorder_packets_Al,
reorder_packets_Stas );
exit(0);
}
l++。 rは(r+1)%MAXNと等しいです。 (j=0、;j<分(l、MAXN)、seqnum<リング[輪(r-j-1)](+ +) j iReturn=1) リング[r]はseqnumと等しいです。 iReturnを返してください。 intメイン、(int argc、炭*argv[]){ int i、パケット。 (i=1。 i<argc。 i++)、_パケット++を受けてください。 パケット=atoi、(argv[i])。 追加注文_パケット_アル+=testorder1(パケット)。 //単独個体追加注文_パケット_スタース+=testorder2(パケット)。 //n-reord。 } printf(___パケット、追加注文_パケットアルは、「容認されたパケットが%dと等しく、シングルトンReorderedは%dと等しく、n再命令された=%dは\nです」と受けて、追加注文_パケットはスタースです)。 出口(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、/心臓、.1:2001 (E)。 また、発行されています:
The C Standard: Incorporating Technical Corrigendum 1, British Standards Institute, ISBN: 0-470-84573-2, Hardcover, 558 pages, September 2003.
C規格: 技術的な間違い1を取り入れるイギリスの規格研究所、ISBN: 0-470-84573-2と、Hardcover、558ページと、2003年9月。
Morton, et al. Standards Track [Page 40] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[40ページ]。
Appendix B. Fragment Order Evaluation (Informative)
付録B.断片オーダー評価(有益)です。
Section 3 stated that fragment reassembly is assumed prior to order evaluation, but that similar procedures could be applied prior to reassembly. This appendix gives definitions and procedures to identify reordering in a packet stream that includes fragmentation.
セクション3は、断片再アセンブリがオーダー評価の前に想定されましたが、再アセンブリの前で同様の手順を適用できると述べました。 この付録は特定する断片化を含んでいるパケットの流れで再命令される定義と手順を与えます。
B.1. Metric Name
B.1。 メートル法の名前
The Metric retains the same name, Type-P-Reordered, but additional parameters are required.
Type-P-Reordered、Metricは同じ名前を保有しますが、追加パラメタが必要です。
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.
この付録は、断片オフセットを昇るのに応じてパケットを断片に分割する装置がそれらを送ると仮定します。 早めのリナックスOSが逆順で断片を送ったので、この可能性はチェックする価値があります。
B.2. Additional Metric Parameters
B.2。 追加メートル法のパラメタ
+ MoreFrag, the state of the More Fragments Flag in the IP header.
+ MoreFrag、IPヘッダーのMore Fragments Flagの州。
+ FragOffset, the offset from the beginning of a fragmented packet,
in 8 octet units (also from the IP header).
+ 8八重奏ユニットの断片化しているパケット(IPヘッダーからも)の始まりからのFragOffset、オフセット。
+ 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.
+ 再命令するために現在評価での断片化しているパケットのIPヘッダーからのFragSeq#、一連番号。 ゼロに設定される場合、断片評価は進行していません。
+ 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.
無くなるとなくなった断片があるパケットを宣言しなければならなくて、サンプル測定基準から届くどんな断片のReordering状態も除かなければならないことに注意してください。
Morton, et al. Standards Track [Page 41] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[41ページ]。
B.3. Definition
B.3。 定義
The value of Type-P-Reordered is typically false (the packet is in-order) when
Type-P-Reorderedの値が通常誤っている、(パケットは整然としています)いつ
* the sequence number s >= NextExp, AND
* 一連番号s>はNextExp、ANDと等しいです。
* the fragment offset FragOffset >= NextExpFrag
* 断片はFragOffset>=NextExpFragを相殺しました。
However, it is more efficient to define reordered conditions exactly and designate Type-P-Reordered as False otherwise.
しかしながら、まさに再命令された状態を定義して、そうでなければ、FalseとしてType-P-Reorderedを指定するのは、より効率的です。
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#
ケース2: s<FragSeq#です。
Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag
ケース3: s>がNextExpと等しく、sがFragSeq#とFragOffset<NextExpFragと等しいなら
This definition can also be illustrated in pseudo-code. A version of the code follows, and some simplification may be possible. Housekeeping for the new parameters will be challenging.
また、中間コードでこの定義を例証できます。 コードのバージョンは従います、そして、何らかの簡素化が可能であるかもしれません。 新しいパラメタのための家事はやりがいがあるでしょう。
NextExp=0; NextExpFrag=0; FragSeq#=0;
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 */
ゆったり過ごす(パケットはsと共に到着します、MoreFrag、FragOffset)、a正常なパケットか最終が破片手榴弾で殺傷するFragSeq#が0; NextExpFrag=0; Reorderingと= 虚偽で等しいというオーダーにおけるパケットの到着した*/NextExp=s+1の(s>はNextExpとMoreFrag==0と等しいです、そして、s>はFragSeq#と等しいです)/*; (s>=NextExp、MoreFrag==1、およびs>FragSeq#>=0) 新しいパケットの/*a断片は届きました、ことによると現在の断片化しているパケット*/FragSeq#=sより高い一連番号で; NextExpFragはFragOffset+1と等しいです; Reordering=偽、(NextExp、MoreFrag==1、およびs>=s==FragSeq#)である、「現在のパケットs」到着した*/の/*a断片
Morton, et al. Standards Track [Page 42] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[42ページ]。
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;
}
}
Reorderingが偽と等しいというほかの(FragOffset>はNextExpFragと等しいです)NextExpFrag=FragOffset+1である、Reordering、= 本当に、/*断片が*/を再命令した、(NextExp、MoreFrag==1、およびs<s>=FragSeq#)である、唯一の、そして、余分な本当のほかの下の*/Reordering=でイラストのための遅い断片が届いた/*ケース。 ほか、/*いつs<NextExp、またはMoreFrag==0とs<FragSeq#*/Reordering=、本当。 } }
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.
コードの働くバージョンはさらにReordered状態を使用する前にパケットのすべての断片が届くのを保証するためにチェックを含んでいるでしょう、サンプル測定基準などのように。
B.4. Discussion: Notes on Sample Metrics When Evaluating Fragments
B.4。 議論: サンプル測定基準では、評価がいつ断片化するかに注意します。
All fragments with the same source sequence number are assigned the same source time.
同じソース一連番号があるすべての断片が同ソース時に割り当てられます。
Evaluation with byte stream numbering may be simplified if the fragment offset is simply added to the SourceByte of the first packet (with fragment offset = 0), keeping the 8 octet units of the offset in mind.
断片オフセットが単に最初のパケット(断片オフセット=0がある)のSourceByteに加えられるなら、バイト・ストリーム付番による評価は簡素化されるかもしれません、念頭にオフセットの8八重奏ユニットを保って。
Appendix C. Disclaimer and License
付録C.注意書きとライセンス
Regarding this entire document or any portion of it (including the pseudo-code and C code), the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.
それ(中間コードとCコードを含んでいる)のこの全体のドキュメントかどんな部分に関しても、作者は、保証を全くしないで、また使用から生じるどんな損害にも責任がありません。 作者は他の誰もそれを使用して、変更して、分配する権利を減少させないどんな方法でもそれを使用して、変更して、分配するために呼び戻せない許可をだれにも与えます、再配付された派生している作品が紛らわしい作者かバージョン情報を含んでいなければ。 派生している作品は同類項に基づき認可される必要はありません。
Morton, et al. Standards Track [Page 43] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[43ページ]。
Authors' Addresses
作者のアドレス
Al Morton AT&T Labs Room D3 - 3C06 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 1571 EMail: acmorton@att.com
アルモートンAT&T研究室Room D3--3C06 200ローレルAve。 南ミドルタウン、ニュージャージー 米国電話+1 732 420 1571がメールする07748: acmorton@att.com
Len Ciavattone AT&T Labs Room A2 - 4G06 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 1239 EMail: lencia@att.com
レンCiavattone AT&T研究室Room A2--4G06 200ローレルAve。 南ミドルタウン、ニュージャージー 米国電話+1 732 420 1239がメールする07748: lencia@att.com
Gomathi Ramachandran AT&T Labs Room C4 - 3D22 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 2353 EMail: gomathi@att.com
GomathiラマチャンドランAT&T研究室Room C4--3D22 200ローレルAve。 南ミドルタウン、ニュージャージー 米国電話+1 732 420 2353がメールする07748: gomathi@att.com
Stanislav Shalunov Internet2 1000 Oakbrook DR STE 300 Ann Arbor, MI 48104 Phone: +1 734 995 7060 EMail: shalunov@internet2.edu
アナーバー、スタニスラフShalunov Internet2 1000Oakbrook DR STE300MI 48104は以下に電話をします。 +1 7060年の734 995メール: shalunov@internet2.edu
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton, OR 97008 USA Phone: +1 818 338 4112 EMail: jperser@veriwave.com
ジェリーPerser Veriwave8770SW雨雲Ave。 スイートBビーバートン、または97008米国電話: +1 4112年の818 338メール: jperser@veriwave.com
Morton, et al. Standards Track [Page 44] RFC 4737 Packet Reordering Metrics November 2006
モートン、他 規格はパケットReordering測定基準2006年11月にRFC4737を追跡します[44ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Morton, et al. Standards Track [Page 45]
モートン、他 標準化過程[45ページ]
一覧
スポンサーリンク
