[要約] RFC 8250は、IPv6ネットワークのパフォーマンスと診断メトリクスを提供するためのDestination Optionを定義しています。このRFCの目的は、ネットワークのトラブルシューティングやパフォーマンスの改善に役立つ情報を提供することです。
Internet Engineering Task Force (IETF) N. Elkins
Request for Comments: 8250 Inside Products
Category: Standards Track R. Hamilton
ISSN: 2070-1721 Chemical Abstracts Service
M. Ackermann
BCBS Michigan
September 2017
IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
IPv6パフォーマンスおよび診断メトリック（PDM）宛先オプション
Abstract
概要
To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.
パフォーマンスの問題を評価するために、このドキュメントでは、測定の基礎としてシーケンス番号とタイミング情報を提供する、各パケットに埋め込まれたオプションのヘッダーについて説明します。そのような測定は、リアルタイムでまたは事後に解釈され得る。このドキュメントでは、パフォーマンスと診断メトリック（PDM）の宛先オプションヘッダーを指定します。 PDMの測定におけるフィールドの制限、計算、および使用法は、このドキュメントに含まれています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8250.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8250で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Background ......................................................3
1.1. Terminology ................................................3
1.2. Rationale for Defined Solution .............................4
1.3. IPv6 Transition Technologies ...............................4
2. Measurement Information Derived from PDM ........................5
2.1. Round-Trip Delay ...........................................5
2.2. Server Delay ...............................................5
3. Performance and Diagnostic Metrics Destination Option Layout ....6
3.1. Destination Options Header .................................6
3.2. Performance and Diagnostic Metrics Destination Option ......6
3.2.1. PDM Layout ..........................................6
3.2.2. Base Unit for Time Measurement ......................8
3.3. Header Placement ...........................................9
3.4. Header Placement Using IPsec ESP Mode ......................9
3.4.1. Using ESP Transport Mode ...........................10
3.4.2. Using ESP Tunnel Mode ..............................10
3.5. Implementation Considerations .............................10
3.5.1. PDM Activation .....................................10
3.5.2. PDM Timestamps .....................................10
3.6. Dynamic Configuration Options .............................11
3.7. Information Access and Storage ............................11
4. Security Considerations ........................................11
4.1. Resource Consumption and Resource Consumption Attacks .....11
4.2. Pervasive Monitoring ......................................12
4.3. PDM as a Covert Channel ...................................12
4.4. Timing Attacks ............................................13
5. IANA Considerations ............................................13
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................14
Appendix A. Context for PDM .......................................15
A.1. End-User Quality of Service (QoS) ..........................15
A.2. Need for a Packet Sequence Number (PSN) ....................15
A.3. Rationale for Defined Solution .............................15
A.4. Use PDM with Other Headers .................................16
Appendix B. Timing Considerations .................................16
B.1. Calculations of Time Differentials .........................16
B.2. Considerations of This Time-Differential Representation ....18
B.2.1. Limitations with This Encoding Method ..................18
B.2.2. Loss of Precision Induced by Timer Value Truncation ....19
Appendix C. Sample Packet Flows ...................................20
C.1. PDM Flow - Simple Client-Server Traffic ....................20
C.1.1. Step 1 .................................................20
C.1.2. Step 2 .................................................21
C.1.3. Step 3 .................................................21
C.1.4. Step 4 .................................................23
C.1.5. Step 5 .................................................24
C.2. Other Flows ................................................24
C.2.1. PDM Flow - One-Way Traffic .............................24
C.2.2. PDM Flow - Multiple-Send Traffic .......................25
C.2.3. PDM Flow - Multiple-Send Traffic with Errors ...........26
Appendix D. Potential Overhead Considerations .....................28
Acknowledgments ...................................................30
Authors' Addresses ................................................30
To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real time or after the fact.
パフォーマンスの問題を評価するために、オプションのシーケンス番号とタイミングに基づく測定を各パケットに埋め込むことができます。そのような測定は、リアルタイムでまたは事後に解釈され得る。
As defined in RFC 8200 [RFC8200], destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 node given as the destination address in the IPv6 header, not by routers or other "middleboxes". This document specifies the Performance and Diagnostic Metrics (PDM) destination option. The field limits, calculations, and usage in measurement of the PDM Destination Options header are included in this document.
RFC 8200 [RFC8200]で定義されているように、宛先オプションはIPv6宛先オプション拡張ヘッダーによって運ばれます。宛先オプションには、ルーターやその他の「ミドルボックス」ではなく、IPv6ヘッダーの宛先アドレスとして指定されたIPv6ノードのみが検査する必要があるオプション情報が含まれています。このドキュメントでは、パフォーマンスと診断メトリック（PDM）の宛先オプションを指定します。 PDM宛先オプションヘッダーの測定におけるフィールドの制限、計算、および使用法は、このドキュメントに含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The current IPv6 specification does not provide timing, nor does it provide a similar field in the IPv6 main header or in any extension header. The IPv6 PDM destination option provides such fields.
現在のIPv6仕様ではタイミングは提供されておらず、IPv6メインヘッダーや拡張ヘッダーに同様のフィールドも提供されていません。 IPv6 PDM宛先オプションはそのようなフィールドを提供します。
Advantages include:
利点は次のとおりです。
1. Real measure of actual transactions.
1. 実際のトランザクションの実際の測定。
2. Ability to span organizational boundaries with consistent instrumentation.
2. 一貫したインストルメンテーションで組織の境界をまたぐ能力。
3. No time synchronization needed between session partners.
3. セッションパートナー間で時間を同期する必要はありません。
4. Ability to handle all transport protocols (TCP, UDP, the Stream Control Transmission Protocol (SCTP), etc.) in a uniform way.
4. すべてのトランスポートプロトコル（TCP、UDP、ストリーム制御伝送プロトコル（SCTP）など）を統一された方法で処理する機能。
PDM provides the ability to determine quickly if the (latency) problem is in the network or in the server (application). That is, it is a fast way to do triage. For more information on the background and usage of PDM, see Appendix A.
PDMは、（レイテンシ）問題がネットワークにあるのか、サーバー（アプリケーション）にあるのかをすばやく判断する機能を提供します。つまり、トリアージを行うための迅速な方法です。 PDMの背景と使用法の詳細については、付録Aを参照してください。
In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed. It is possible that an IPv6 packet containing PDM may be dropped if using IPv6 transition technologies. For example, an implementation using a translation technique (IPv6 to IPv4) that does not support or recognize the IPv6 Destination Options extension header may simply drop the packet rather than translating it without the extension header.
IPv6の完全な実装への道のりで、変換やトンネリングなどの移行テクノロジが採用される可能性があります。 IPv6移行テクノロジーを使用している場合、PDMを含むIPv6パケットがドロップされる可能性があります。たとえば、IPv6宛先オプション拡張ヘッダーをサポートまたは認識しない変換技法（IPv6からIPv4）を使用する実装は、拡張ヘッダーなしでパケットを変換するのではなく、単にパケットをドロップする場合があります。
It is also possible that some devices in the network may not correctly handle multiple IPv6 extension headers, including the IPv6 Destination Option. For example, adding the PDM header to a packet may push the Layer 4 information to a point in the packet where it is not visible to filtering logic, and the packet may be dropped. This kind of situation is expected to become rare over time.
ネットワーク内の一部のデバイスが、IPv6宛先オプションを含む複数のIPv6拡張ヘッダーを正しく処理しない可能性もあります。たとえば、PDMヘッダーをパケットに追加すると、レイヤー4情報がパケットのポイントにプッシュされ、フィルタリングロジックからは見えなくなり、パケットがドロップされる場合があります。このような状況は、時間の経過とともにまれになると予想されます。
Each packet contains information about the sender and receiver. In IP, the identifying information is called a "5-tuple".
各パケットには、送信者と受信者に関する情報が含まれています。 IPでは、識別情報は「5タプル」と呼ばれます。
The 5-tuple consists of:
5タプルは以下で構成されます。
SADDR: IP address of the sender SPORT: Port for the sender DADDR: IP address of the destination DPORT: Port for the destination PROTC: Upper-layer protocol (TCP, UDP, ICMP, etc.)
SADDR：送信者のIPアドレスSPORT：送信者のポートDADDR：宛先のIPアドレスDPORT：宛先のポートPROTC：上位層プロトコル（TCP、UDP、ICMPなど）
PDM contains the following base fields (scale fields intentionally left out):
PDMには、次の基本フィールドが含まれています（スケールフィールドは意図的に省略されています）。
PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTATLR: Delta Time Last Received DELTATLS: Delta Time Last Sent
PSNTP：このパケットのシーケンス番号このパケットPSNLR：最後に受信したパケットシーケンス番号DELTATLR：最後に受信したデルタ時間DELTATLS：最後に送信したデルタ時間
Other fields for storing time scaling factors are also in PDM and will be described in Section 3.
時間スケーリング係数を格納する他のフィールドもPDMにあり、セクション3で説明します。
This information, combined with the 5-tuple, allows the measurement of the following metrics:
この情報と5タプルを組み合わせると、次のメトリックを測定できます。
1. Round-trip delay
1. 往復遅延
2. Server delay
2. サーバーの遅延
Round-trip *network* delay is the delay for packet transfer from a source host to a destination host and then back to the source host. This measurement has been defined, and its advantages and disadvantages are discussed in "A Round-trip Delay Metric for IPPM" [RFC2681].
ラウンドトリップ*ネットワーク*遅延とは、送信元ホストから宛先ホストへのパケット転送と、その後送信元ホストへのパケット転送の遅延です。この測定は定義されており、その長所と短所は「IPPMの往復遅延メトリック」[RFC2681]で説明されています。
Server delay is the interval between when a packet is received by a device and the first corresponding packet is sent back in response. This may be "server processing time". It may also be a delay caused by acknowledgments. Server processing time includes the time taken by the combination of the stack and application to return the response. The stack delay may be related to network performance. If this aggregate time is seen as a problem and there is a need to make a clear distinction between application processing time and stack delay, including that caused by the network, then more client-based measurements are needed.
サーバー遅延は、パケットがデバイスによって受信されてから、最初の対応するパケットが応答として返送されるまでの間隔です。これは「サーバー処理時間」の場合があります。また、確認応答により遅延が発生する場合もあります。サーバーの処理時間には、スタックとアプリケーションの組み合わせが応答を返すのにかかる時間が含まれます。スタック遅延は、ネットワークパフォーマンスに関連している可能性があります。この合計時間が問題と見なされ、アプリケーションの処理時間とスタックの遅延（ネットワークによって引き起こされるものも含む）を明確に区別する必要がある場合は、より多くのクライアントベースの測定が必要です。
The IPv6 Destination Options extension header [RFC8200] is used to carry optional information that needs to be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header and is defined in RFC 8200 [RFC8200]. The IPv6 Performance and Diagnostic Metrics (PDM) destination option is implemented as an IPv6 Option carried in the Destination Options header. PDM does not require time synchronization.
IPv6宛先オプション拡張ヘッダー[RFC8200]は、パケットの宛先ノードのみが検査する必要があるオプション情報を運ぶために使用されます。 Destination Optionsヘッダーは、直前のヘッダーの60のNext Header値によって識別され、RFC 8200 [RFC8200]で定義されています。 IPv6パフォーマンスおよび診断メトリック（PDM）宛先オプションは、宛先オプションヘッダーに含まれるIPv6オプションとして実装されます。 PDMは時間同期を必要としません。
The IPv6 PDM destination option contains the following fields:
IPv6 PDM宛先オプションには、次のフィールドが含まれています。
SCALEDTLR: Scale for Delta Time Last Received SCALEDTLS: Scale for Delta Time Last Sent PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTATLR : Delta Time Last Received DELTATLS : Delta Time Last Sent
SCALEDTLR：最後に受信したデルタ時間のスケールSCALEDTLS：最後に送信したデルタ時間のスケールPSNTP：最後に受信したパケットシーケンス番号PSNLR：最後に受信したパケットシーケンス番号DELTATLR：最後に受信したデルタ時間DELTATLS：最後に送信した時間
PDM has alignment requirements. Following the convention in IPv6, these options are aligned in a packet so that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8) [RFC8200].
PDMには調整要件があります。 IPv6の規則に従って、これらのオプションはパケット内で整列されるため、各オプションのオプションデータフィールド内のマルチオクテット値は自然境界に含まれます（つまり、幅nオクテットのフィールドは、nオクテットの整数倍に配置されます）ヘッダーの開始、n = 1、2、4、または8の場合[RFC8200]。
The PDM destination option is encoded in type-length-value (TLV) format as follows:
PDM宛先オプションは、type-length-value（TLV）形式で次のようにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | ScaleDTLR | ScaleDTLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN This Packet | PSN Last Received |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time Last Received | Delta Time Last Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
0x0F
0x0F
In keeping with RFC 8200 [RFC8200], the two high-order bits of the Option Type field are encoded to indicate specific processing of the option; for the PDM destination option, these two bits MUST be set to 00.
RFC 8200 [RFC8200]に準拠して、オプションタイプフィールドの上位2ビットがエンコードされ、オプションの特定の処理を示します。 PDM宛先オプションの場合、これらの2ビットは00に設定する必要があります。
The third high-order bit of the Option Type field specifies whether or not the Option Data of that option can change en route to the packet's final destination.
Option Typeフィールドの3番目の上位ビットは、そのオプションのOption Dataがパケットの最終宛先への途中で変更できるかどうかを指定します。
In PDM, the value of the third high-order bit MUST be 0.
PDMでは、3番目の上位ビットの値は0でなければなりません。
Option Length
オプションの長さ
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 10.
8ビットの符号なし整数。オプションの長さ（オクテット単位）。[オプションタイプ]フィールドと[オプションの長さ]フィールドは含まれません。このフィールドは10に設定する必要があります。
Scale Delta Time Last Received (SCALEDTLR)
デルタ時間の最後の受信のスケール（SCALEDTLR）
8-bit unsigned integer. This is the scaling value for the Delta Time Last Received (DELTATLR) field. The possible values are from 0 to 255. See Appendix B for further discussion on timing considerations and formatting of the scaling values.
8ビットの符号なし整数。これは、最後に受信したデルタ時間（DELTATLR）フィールドのスケーリング値です。可能な値は0〜255です。タイミングの考慮事項とスケーリング値のフォーマットの詳細については、付録Bを参照してください。
Scale Delta Time Last Sent (SCALEDTLS)
最後に送信されたデルタ時間のスケール（SCALEDTLS）
8-bit signed integer. This is the scaling value for the Delta Time Last Sent (DELTATLS) field. The possible values are from 0 to 255.
8ビットの符号付き整数。これは、Delta Time Last Sent（DELTATLS）フィールドのスケーリング値です。可能な値は0〜255です。
Packet Sequence Number This Packet (PSNTP)
パケットシーケンス番号このパケット（PSNTP）
16-bit unsigned integer. This field will wrap. It is intended for use while analyzing packet traces.
16ビット符号なし整数。このフィールドは折り返されます。パケットトレースの分析中に使用することを目的としています。
This field is initialized at a random number and incremented monotonically for each packet of the session flow of the 5-tuple. The random-number initialization is intended to make it harder to spoof and insert such packets.
このフィールドは、乱数で初期化され、5タプルのセッションフローのパケットごとに単調に増加します。乱数の初期化は、そのようなパケットのなりすましや挿入を困難にすることを目的としています。
Operating systems MUST implement a separate packet sequence number counter per 5-tuple.
オペレーティングシステムは、5タプルごとに個別のパケットシーケンス番号カウンターを実装する必要があります。
Packet Sequence Number Last Received (PSNLR)
最後に受信したパケットシーケンス番号（PSNLR）
16-bit unsigned integer. This is the PSNTP of the packet last received on the 5-tuple.
16ビット符号なし整数。これは、5タプルで最後に受信されたパケットのPSNTPです。
This field is initialized to 0.
このフィールドは0に初期化されます。
Delta Time Last Received (DELTATLR)
デルタ最終受信時刻（DELTATLR）
16-bit unsigned integer. The value is set according to the scale in SCALEDTLR.
16ビット符号なし整数。値は、SCALEDTLRのスケールに従って設定されます。
Delta Time Last Received = (send time packet n - receive time packet (n - 1))
Delta Time Last Received =（送信時間パケットn-受信時間パケット（n-1））
Delta Time Last Sent (DELTATLS)
最後に送信されたデルタ時間（DELTATLS）
16-bit unsigned integer. The value is set according to the scale in SCALEDTLS.
16ビット符号なし整数。値は、SCALEDTLSのスケールに従って設定されます。
Delta Time Last Sent = (receive time packet n - send time packet (n - 1))
最後に送信されたデルタ時間=（受信時間パケットn-送信時間パケット（n-1））
A time differential is always a whole number in a CPU; it is the unit specification -- hours, seconds, nanoseconds -- that determines what the numeric value means. For PDM, the base time unit is 1 attosecond (asec). This allows for a common unit and scaling of the time differential among all IP stacks and hardware implementations.
時間差は常にCPU内の整数です。数値の意味を決定するのは、時間、秒、ナノ秒の単位指定です。 PDMの場合、基本時間単位は1アト秒（asec）です。これにより、共通の単位と、すべてのIPスタックおよびハードウェア実装間の時間差のスケーリングが可能になります。
Note that PDM provides the ability to measure both time differentials that are extremely small and time differentials in a Delay/Disruption Tolerant Networking (DTN) environment where the delays may be very great. To store a time differential in just 16 bits that must range in this way will require some scaling of the time-differential value.
PDMは、非常に小さい時間差と、遅延が非常に大きくなる可能性がある遅延/破壊耐性ネットワーク（DTN）環境での時間差の両方を測定する機能を提供することに注意してください。このように範囲を設定する必要がある16ビットのみで時間差を格納するには、時間差値のスケーリングが必要になります。
One issue is the conversion from the native time base in the CPU hardware of whatever device is in use to some number of attoseconds. It might seem that this will be an astronomical number, but the conversion is straightforward. It involves multiplication by an appropriate power of 10 to change the value into a number of attoseconds. Then, to scale the value so that it fits into DELTATLR or DELTATLS, the value is shifted by a number of bits, retaining the 16 high-order or most significant bits. The number of bits shifted becomes the scaling factor, stored as SCALEDTLR or SCALEDTLS, respectively. For additional information on this process, see Appendix B.
1つの問題は、使用中のデバイスのCPUハードウェアのネイティブタイムベースから、いくつかのアト秒への変換です。これは天文学的な数値のように見えるかもしれませんが、変換は簡単です。これには、適切な10の累乗を乗算して、値をアト秒数に変更します。次に、値をDELTATLRまたはDELTATLSに収まるようにスケーリングするには、値をビット数だけシフトし、上位16ビットまたは最上位ビットを保持します。シフトされたビット数がスケーリング係数になり、それぞれSCALEDTLRまたはSCALEDTLSとして格納されます。このプロセスの詳細については、付録Bを参照してください。
The PDM destination option is placed as defined in RFC 8200 [RFC8200]. There may be a choice of where to place the Destination Options header. If using Encapsulating Security Payload (ESP) mode, please see Section 3.4 of this document regarding the placement of the PDM Destination Options header.
PDM宛先オプションは、RFC 8200 [RFC8200]の定義に従って配置されます。 Destination Optionsヘッダーを配置する場所を選択できる場合があります。カプセル化セキュリティペイロード（ESP）モードを使用している場合、PDM宛先オプションヘッダーの配置については、このドキュメントのセクション3.4を参照してください。
For each IPv6 packet header, PDM MUST NOT appear more than once. However, an encapsulated packet MAY contain a separate PDM associated with each encapsulated IPv6 header.
IPv6パケットヘッダーごとに、PDMが複数回出現することはできません。ただし、カプセル化されたパケットには、カプセル化された各IPv6ヘッダーに関連付けられた個別のPDMが含まれる場合があります。
IPsec ESP is defined in [RFC4303] and is widely used. Section 3.1.1 of [RFC4303] discusses the placement of Destination Options headers.
IPsec ESPは[RFC4303]で定義され、広く使用されています。 [RFC4303]のセクション3.1.1は、宛先オプションヘッダーの配置について説明しています。
The placement of PDM is different, depending on whether ESP is used in tunnel mode or transport mode.
PDMの配置は、ESPがトンネルモードとトランスポートモードのどちらで使用されているかによって異なります。
In the ESP case, no 5-tuple is available, as there are no port numbers. ESP flow should be identified only by using SADDR, DADDR, and PROTC. The Security Parameter Index (SPI) numbers SHOULD be ignored when considering the flow over which PDM information is measured.
ESPの場合、ポート番号がないため、5タプルは使用できません。 ESPフローは、SADDR、DADDR、およびPROTCを使用することによってのみ識別されます。 PDM情報が測定されるフローを検討するときは、セキュリティパラメータインデックス（SPI）番号を無視してください。
Note that destination options may be placed before or after ESP, or both. If using PDM in ESP transport mode, PDM MUST be placed after the ESP header so as not to leak information.
宛先オプションはESPの前または後、あるいはその両方に配置できることに注意してください。 ESPトランスポートモードでPDMを使用する場合、情報を漏らさないように、ESPヘッダーの後にPDMを配置する必要があります。
Note that in both the outer set of IP headers and the inner set of IP headers, destination options may be placed before or after ESP, or both. A tunnel endpoint that creates a new packet may decide to use PDM independently of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints.
IPヘッダーの外部セットとIPヘッダーの内部セットの両方で、宛先オプションはESPの前または後、あるいはその両方に配置できます。新しいパケットを作成するトンネルエンドポイントは、元のパケットのPDMの使用とは無関係にPDMを使用して、2つのトンネルエンドポイント間の遅延測定を有効にすることを決定できます。
An implementation should provide an interface to enable or disable the use of PDM. This specification recommends having PDM off by default.
実装は、PDMの使用を有効または無効にするインターフェースを提供する必要があります。この仕様では、デフォルトでPDMをオフにすることを推奨しています。
PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device.
パケットがPDMヘッダーとともに受信された場合にのみ、PDMをオンにしてはなりません。受信したパケットは、別のデバイスによってスプーフィングされる可能性があります。
The PDM timestamps are intended to isolate wire time from server or host time but may necessarily attribute some host processing time to network latency.
PDMタイムスタンプは、サーバーまたはホストの時間からワイヤ時間を分離することを目的としていますが、一部のホストの処理時間は、ネットワーク遅延に起因している可能性があります。
Section 10.2 of RFC 2330 [RFC2330] ("Framework for IP Performance Metrics") describes two notions of "wire time". These notions are only defined in terms of an Internet host H observing an Internet link L at a particular location:
RFC 2330 [RFC2330]のセクション10.2（「IPパフォーマンスメトリックのフレームワーク」）では、「ワイヤタイム」の2つの概念について説明しています。これらの概念は、特定の場所でインターネットリンクLを監視するインターネットホストHに関してのみ定義されます。
+ For a given IP packet P, the "wire arrival time" of P at H on L is the first time T at which any bit of P has appeared at H's observational position on L.
+ 特定のIPパケットPの場合、L上のHでのPの「ワイヤ到着時間」は、Pの任意のビットがL上のHの観測位置に現れた最初の時間Tです。
+ For a given IP packet P, the "wire exit time" of P at H on L is the first time T at which all the bits of P have appeared at H's observational position on L.
+ 特定のIPパケットPの場合、L上のHにおけるPの「ワイヤ出口時間」は、PのすべてのビットがL上のHの観測位置に現れた最初の時間Tです。
This specification does not define H's exact observational position on L. That is left for the deployment setups to define. However, the position where PDM timestamps are taken SHOULD be as close to the physical network interface as possible. Not all implementations will be able to achieve the ideal level of measurement.
この仕様は、L上のHの正確な観測位置を定義していません。それは、展開セットアップが定義するために残されています。ただし、PDMタイムスタンプが取得される位置は、物理ネットワークインターフェイスにできるだけ近い必要があります。すべての実装が理想的な測定レベルを達成できるわけではありません。
If the PDM Destination Options header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc.), a local port, or IP address only. These are at the discretion of the implementation.
PDM宛先オプションヘッダーが使用される場合、ホストを通過するすべてのパケットに対してオンになり、上位層プロトコル（TCP、UDP、SCTPなど）、ローカルポート、またはIPアドレスのみに適用されます（MAY）。これらは実装の裁量にあります。
Measurement information provided by PDM may be made accessible for higher layers or the user itself. Similar to activating the use of PDM, the implementation may also provide an interface to indicate if received.
PDMによって提供される測定情報は、上位層またはユーザー自身がアクセスできるようにすることができます。 PDMの使用をアクティブにするのと同様に、実装は、受信したかどうかを示すインターフェースも提供します。
PDM information may be stored, if desired. If a packet with PDM information is received and the information should be stored, the upper layers may be notified. Furthermore, the implementation should define a configurable maximum lifetime after which the information can be removed as well as a configurable maximum amount of memory that should be allocated for PDM information.
必要に応じて、PDM情報を保存できます。 PDM情報を含むパケットを受信し、その情報を保存する必要がある場合は、上位層に通知されます。さらに、実装では、構成可能な最大有効期間を定義してから、情報を削除できます。また、PDM情報に割り当てる必要がある構成可能な最大メモリ容量も定義する必要があります。
PDM may introduce some new security weaknesses.
PDMはいくつかの新しいセキュリティの弱点を導入するかもしれません。
PDM needs to calculate the deltas for time and keep track of the sequence numbers. This means that control blocks that reside in memory may be kept at the end hosts per 5-tuple.
PDMは時間のデルタを計算し、シーケンス番号を追跡する必要があります。つまり、メモリに常駐する制御ブロックは、5タプルごとにエンドホストに保持される可能性があります。
A limit on how much memory is being used SHOULD be implemented.
使用されるメモリ量の制限を実装する必要があります。
Without a memory limit, any time that a control block is kept in memory, an attacker can try to misuse the control blocks to cause excessive resource consumption. This could be used to compromise the end host.
メモリ制限がないと、制御ブロックがメモリに保持されているときはいつでも、攻撃者は制御ブロックを誤用して過剰なリソース消費を引き起こす可能性があります。これは、エンドホストを危険にさらすために使用される可能性があります。
PDM is used only at the end hosts, and memory is used only at the end host and not at routers or middleboxes.
PDMはエンドホストでのみ使用され、メモリはエンドホストでのみ使用され、ルーターやミドルボックスでは使用されません。
Since PDM passes in the clear, a concern arises as to whether the data can be used to fingerprint the system or somehow obtain information about the contents of the payload.
PDMはクリアテキストで渡されるため、データを使用してシステムのフィンガープリントを作成できるか、それともペイロードの内容に関する情報を何らかの方法で取得できるかという懸念が生じます。
Let us discuss fingerprinting of the end host first. It is possible that seeing the pattern of deltas or the absolute values could give some information as to the speed of the end host -- that is, if it is a very fast system or an older, slow device. This may be useful to the attacker. However, if the attacker has access to PDM, the attacker also has access to the entire packet and could make such a deduction based merely on the time frames elapsed between packets WITHOUT PDM.
最初にエンドホストのフィンガープリントについて説明します。デルタのパターンまたは絶対値を確認すると、エンドホストの速度に関する情報が得られる可能性があります。つまり、非常に高速なシステムまたは古い、遅いデバイスの場合です。これは攻撃者にとって有用な場合があります。ただし、攻撃者がPDMにアクセスできる場合、攻撃者はパケット全体にもアクセスでき、PDMを使用しないパケット間で経過した時間フレームのみに基づいてこのような推論を行う可能性があります。
As far as deducing the content of the payload, in terms of the application-level information such as web page, user name, user password, and so on, it appears to us that PDM is quite unhelpful in this regard. Having said that, the ability to separate wire time from processing time may potentially provide an attacker with additional information. It is conceivable that an attacker could attempt to deduce the type of application in use by noting the server time and payload length. Some encryption algorithms attempt to obfuscate the packet length to avoid just such vulnerabilities. In the future, encryption algorithms may wish to obfuscate the server time as well.
ペイロードのコンテンツを推測する限り、Webページ、ユーザー名、ユーザーパスワードなどのアプリケーションレベルの情報に関しては、PDMはこの点でまったく役に立たないように見えます。とは言っても、処理時間からワイヤ時間を分離する機能は、攻撃者に追加情報を提供する可能性があります。攻撃者がサーバーの時間とペイロードの長さに注意することにより、使用中のアプリケーションのタイプを推測することを試みることが考えられます。一部の暗号化アルゴリズムは、パケット長を難読化して、このような脆弱性のみを回避しようとします。将来的には、暗号化アルゴリズムによってサーバー時間も難読化される可能性があります。
PDM provides a set of fields in the packet that could be used to leak data. But there is no real reason to suspect that PDM would be chosen rather than another part of the payload or another extension header.
PDMは、データのリークに使用される可能性があるパケット内の一連のフィールドを提供します。しかし、ペイロードまたは別の拡張ヘッダーの別の部分ではなく、PDMが選択されると疑う実際の理由はありません。
A firewall or another device could sanity-check the fields within PDM, but randomly assigned sequence numbers and delta times might be expected to vary widely. The biggest problem, though, is how an attacker would get access to PDM in the first place to leak data. The attacker would have to either compromise the end host or have a Man in the Middle (MitM). It is possible that either one could change the fields, but the other end host would then get sequence numbers and deltas that don't make any sense.
ファイアウォールまたは別のデバイスは、PDM内のフィールドを正常性チェックできますが、ランダムに割り当てられたシーケンス番号とデルタ時間は大きく異なることが予想されます。ただし、最大の問題は、攻撃者が最初にPDMにアクセスしてデータを漏洩させる方法です。攻撃者は、エンドホストを危険にさらすか、中間者（MitM）にする必要があります。どちらか一方がフィールドを変更する可能性がありますが、もう一方のエンドホストはシーケンス番号と意味のないデルタを取得します。
It is conceivable that someone could compromise an end host and make it start sending packets with PDM without the knowledge of the host. But, again, the bigger problem is the compromise of the end host. Once that is done, the attacker probably has better ways to leak data.
誰かがエンドホストを危険にさらし、ホストに気付かれずにPDMでパケットの送信を開始させることが考えられます。しかし、再び、より大きな問題はエンドホストの侵害です。それが完了したら、攻撃者はおそらくデータをリークするより良い方法を持っています。
Having said that, if a PDM-aware middlebox or an implementation (destination host) detects some number of "nonsensical" sequence numbers or timing information, it could take action to block this traffic, discard it, or send an alert.
そうは言っても、PDM認識ミドルボックスまたは実装（宛先ホスト）がいくつかの「無意味な」シーケンス番号またはタイミング情報を検出した場合、このトラフィックをブロックするか、破棄するか、アラートを送信するアクションを実行できます。
The fact that PDM can help in the separation of node processing time from network latency brings value to performance monitoring. Yet, it is this very characteristic of PDM that may be misused to make certain new types of timing attacks against protocols and implementations possible.
PDMがノード処理時間をネットワーク遅延から分離するのに役立つという事実は、パフォーマンス監視に価値をもたらします。それでも、プロトコルと実装に対する特定の新しいタイプのタイミング攻撃を可能にするために誤用される可能性があるのは、PDMのこの非常に特性です。
Depending on the nature of the cryptographic protocol used, it may be possible to leak the credentials of the device. For example, if an attacker can see that PDM is being used, then the attacker might use PDM to launch a timing attack against the keying material used by the cryptographic protocol.
使用される暗号化プロトコルの性質によっては、デバイスの資格情報が漏洩する可能性があります。たとえば、攻撃者がPDMが使用されていることを確認できる場合、攻撃者はPDMを使用して、暗号化プロトコルが使用するキーイングマテリアルに対してタイミング攻撃を仕掛ける可能性があります。
An implementation may want to be sure that PDM is enabled only for certain IP addresses or only for some ports. Additionally, the implementation SHOULD require an explicit restart of monitoring after a certain time period (for example, after 1 hour) to make sure that PDM is not accidentally left on (for example, after debugging has been done).
実装によっては、PDMが特定のIPアドレスに対してのみ、または一部のポートに対してのみ有効であることを確認したい場合があります。さらに、実装では、PDMが誤ってオンになっていないことを確認するために（たとえば、デバッグが行われた後など）、一定の期間（たとえば、1時間後）後に監視を明示的に再起動する必要があります（SHOULD）。
Even so, if using PDM, a user "Consent to be Measured" SHOULD be a prerequisite for using PDM. Consent is common in enterprises and with some subscription services. The actual content of "Consent to be Measured" will differ by site, but it SHOULD make clear that the traffic is being measured for Quality of Service (QoS) and to assist in diagnostics, as well as to make clear that there may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session.
それでも、PDMを使用する場合は、「測定に同意」というユーザーがPDMを使用するための前提条件である必要があります。企業および一部のサブスクリプションサービスでは同意が一般的です。 「測定される同意」の実際の内容はサイトによって異なりますが、トラフィックがサービス品質（QoS）のために測定されていること、および診断を支援すること、および潜在的な可能性があることを明らかにする必要があります診断セッション中にトラフィックがキャプチャされた場合の特定の脆弱性のリスク。
IANA has registered a Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0 from the "Destination Options and Hop-by-Hop Options" sub-registry of the "Internet Protocol Version 6 (IPv6) Parameters" registry [RFC2780] at <https://www.iana.org/assignments/ipv6-parameters/>.
IANAは、「インターネットプロトコルバージョン6（IPv6）パラメータ」の「宛先オプションとホップバイホップオプション」サブレジストリから、actビットを00、chgビットを0に設定して宛先オプションタイプの割り当てを登録しました。レジストリ[RFC2780]（<https://www.iana.org/assignments/ipv6-parameters/>）。
Hex Value Binary Value Description Reference
act chg rest
---------------------------------------------------------------------
0x0F 00 0 01111 Performance and RFC 8250
Diagnostic Metrics (PDM)
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、DOI 10.17487 / RFC2681、1999年9月、<https：//www.rfc-editor .org / info / rfc2681>。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <https://www.rfc-editor.org/info/rfc2780>.
[RFC2780] Bradner、S。およびV. Paxson、「インターネットプロトコルおよび関連ヘッダーの値に関するIANA割り当てガイドライン」、BCP 37、RFC 2780、DOI 10.17487 / RFC2780、2000年3月、<https：//www.rfc- editor.org/info/rfc2780>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、Madhavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<https：//www.rfc -editor.org/info/rfc2330>。
[TCPM] Scheffenegger, R., Kuehlewind, M., and B. Trammell, "Encoding of Time Intervals for the TCP Timestamp Option", Work in Progress, draft-trammell-tcpm-timestamp-interval-01, July 2013.
[TCPM] Scheffenegger、R.、Kuehlewind、M。、およびB. Trammell、「TCP Timestampオプションの時間間隔のエンコーディング」、Work in Progress、draft-trammell-tcpm-timestamp-interval-01、2013年7月。
The timing values in PDM embedded in the packet will be used to estimate QoS as experienced by an end-user device.
パケットに埋め込まれたPDMのタイミング値は、エンドユーザーデバイスが経験するQoSを推定するために使用されます。
For many applications, the key user performance indicator is response time. When the end user is an individual, he is generally indifferent to what is happening along the network; what he really cares about is how long it takes to get a response back. But this is not just a matter of individuals' personal convenience. In many cases, rapid response is critical to the business being conducted.
多くのアプリケーションで、主要なユーザーパフォーマンスインジケーターは応答時間です。エンドユーザーが個人である場合、彼は一般にネットワーク上で起こっていることに無関心です。彼が本当に気にかけているのは、応答が返されるまでにかかる時間です。しかし、これは個人の個人的な都合の問題だけではありません。多くの場合、迅速な対応は、実施されているビジネスにとって重要です。
Low, reliable, and acceptable response times are not just "nice to have". On many networks, the impact can be financial hardship or can endanger human life. In some cities, the emergency police contact system operates over IP; all levels of law enforcement use IP networks; transactions on our stock exchanges are settled using IP networks. The critical nature of such activities to our daily lives and financial well-being demands a simple solution to support response-time measurements.
低く、信頼性があり、許容できる応答時間は、単に「便利」ではありません。多くのネットワークでは、影響は経済的困難であるか、人命を危険にさらす可能性があります。一部の都市では、緊急警察連絡システムがIPで運用されています。法執行機関のすべてのレベルでIPネットワークが使用されています。当社の証券取引所での取引は、IPネットワークを使用して決済されます。私たちの日常生活と経済的幸福に対するそのような活動の重要な性質は、応答時間測定をサポートするための簡単なソリューションを必要とします。
While performing network diagnostics on an end-to-end connection, it often becomes necessary to isolate the factors along the network path responsible for problems. Diagnostic data may be collected at multiple places along the path (if possible), or at the source and destination. Then, in post-collection processing, the diagnostic data corresponding to each packet at different observation points must be matched for proper measurements. A sequence number in each packet provides a sufficient basis for the matching process. If need be, the timing fields may be used along with the sequence number to ensure uniqueness.
エンドツーエンド接続でネットワーク診断を実行している間、問題の原因であるネットワークパスに沿った要因を分離することがしばしば必要になります。診断データは、パスに沿った複数の場所（可能な場合）、またはソースと宛先で収集されます。次に、収集後の処理では、適切な測定のために、異なる観測点の各パケットに対応する診断データを照合する必要があります。各パケットのシーケンス番号は、照合プロセスの十分な基礎を提供します。必要に応じて、タイミングフィールドをシーケンス番号とともに使用して、一意性を確保できます。
This method of data collection along the path is of special use for determining where packet loss or packet corruption is happening.
パスに沿ったこのデータ収集方法は、パケット損失またはパケット破損が発生している場所を特定するために特別に使用されます。
The packet sequence number needs to be unique in the context of the session (5-tuple).
パケットシーケンス番号は、セッションのコンテキストで一意である必要があります（5タプル）。
One of the important functions of PDM is to allow you to quickly dispatch the right set of diagnosticians. Within network or server latency, there may be many components. The job of the diagnostician is to rule each one out until the culprit is found.
PDMの重要な機能の1つは、適切な診断担当者を迅速に派遣できるようにすることです。ネットワークまたはサーバーの待ち時間内には、多くのコンポーネントが存在する可能性があります。診断医の仕事は、犯人が見つかるまで一人一人を除外することです。
PDM will fit into this diagnostic picture by quickly telling you how to escalate. PDM will point to either the network area or the server area. Within the server latency, PDM does not tell you whether the bottleneck is in the IP stack, the application, or buffer allocation. Within the network latency, PDM does not tell you which of the network segments or middleboxes is at fault.
PDMは、エスカレーションする方法をすばやく伝えることにより、この診断画像に適合します。 PDMは、ネットワーク領域またはサーバー領域を指します。サーバーの待ち時間内では、PDMはボトルネックがIPスタック、アプリケーション、またはバッファー割り当てのどちらにあるかを通知しません。ネットワーク遅延の範囲内では、PDMはどのネットワークセグメントまたはミドルボックスに障害があるかを通知しません。
What PDM does tell you is whether the problem is in the network or the server.
PDMが教えてくれるのは、問題がネットワークにあるのかサーバーにあるのかです。
For diagnostics, one may want to use PDM with other headers (Layer 2, Layer 3, etc). For example, if PDM is used by a technician (or tool) looking at a packet capture, within the packet capture, they would have available to them the Layer 2 header, IP header (v6 or v4), TCP header, UDP header, ICMP header, SCTP header, or other headers. All information would be looked at together to make sense of the packet flow. The technician or processing tool could analyze, report, or ignore the data from PDM, as necessary.
診断のために、他のヘッダー（レイヤー2、レイヤー3など）でPDMを使用したい場合があります。たとえば、技術者（またはツール）がパケットキャプチャを調べてPDMを使用する場合、パケットキャプチャ内では、レイヤー2ヘッダー、IPヘッダー（v6またはv4）、TCPヘッダー、UDPヘッダー、 ICMPヘッダー、SCTPヘッダー、またはその他のヘッダー。パケットフローを理解するために、すべての情報が一緒に調べられます。技術者または処理ツールは、必要に応じて、PDMからのデータを分析、レポート、または無視できます。
For an example of how PDM can help with TCP retransmission problems, please look at Appendix C.
PDMがTCP再送信の問題を解決する方法の例については、付録Cを参照してください。
When SCALEDTLR or SCALEDTLS is used, it means that the description of the processing applies equally to SCALEDTLR and SCALEDTLS.
SCALEDTLRまたはSCALEDTLSが使用されている場合、処理の説明がSCALEDTLRおよびSCALEDTLSに等しく適用されることを意味します。
The time counter in a CPU is a binary whole number representing a number of milliseconds (msec), microseconds (usec), or even picoseconds (psec). Representing one of these values as attoseconds (asec) means multiplying by 10 raised to some exponent. Refer to this table of equalities:
CPUの時間カウンタは、ミリ秒（msec）、マイクロ秒（usec）、またはピコ秒（psec）を表す2進数の整数です。これらの値の1つをアト秒（asec）として表すことは、10をいくつかの指数に乗算して乗算することを意味します。次の等式の表を参照してください。
Base value = # of sec = # of asec 1000s of asec
--------------- ------------- ------------- -------------
1 second 1 sec 10**18 asec 1000**6 asec
1 millisecond 10**-3 sec 10**15 asec 1000**5 asec
1 microsecond 10**-6 sec 10**12 asec 1000**4 asec
1 nanosecond 10**-9 sec 10**9 asec 1000**3 asec
1 picosecond 10**-12 sec 10**6 asec 1000**2 asec
1 femtosecond 10**-15 sec 10**3 asec 1000**1 asec
For example, if you have a time differential expressed in microseconds, since each microsecond is 10**12 asec, you would multiply your time value by 10**12 to obtain the number of attoseconds. If your time differential is expressed in nanoseconds, you would multiply by 10**9 to get the number of attoseconds.
たとえば、マイクロ秒で表される時間差がある場合、各マイクロ秒は10 ** 12 asecなので、アト秒の数を取得するには、時間値に10 ** 12を掛けます。時間差がナノ秒で表される場合は、10 ** 9を掛けてアト秒の数を取得します。
The result is a binary value that will need to be shortened by a number of bits so it will fit into the 16-bit PDM delta field.
結果は、16ビットのPDMデルタフィールドに収まるようにビット数で短縮する必要があるバイナリ値です。
The next step is to divide by 2 until the value is contained in just 16 significant bits. The exponent of the value in the last column of the table is useful here; the initial scaling factor is that exponent multiplied by 10. This is the minimum number of low-order bits to be shifted out or discarded. It represents dividing the time value by 1024 raised to that exponent.
次のステップは、値が16の有効ビットに含まれるまで2で除算することです。テーブルの最後の列の値の指数は、ここで役立ちます。初期のスケーリング係数は、指数に10を掛けたものです。これは、シフトアウトまたは破棄される下位ビットの最小数です。時間値をその指数で累乗した1024で除算したものです。
The resulting value may still be too large to fit into 16 bits but can be normalized by shifting out more bits (dividing by 2) until the value fits into the 16-bit delta field. The number of extra bits shifted out is then added to the scaling factor. The scaling factor -- the total number of low-order bits dropped -- is the SCALEDTLR or SCALEDTLS value.
結果の値はまだ大きすぎて16ビットに収まらない可能性がありますが、値が16ビットのデルタフィールドに収まるまで、さらにビットをシフトアウト（2で除算）することで正規化できます。次に、シフトアウトされた余分なビットの数がスケーリング係数に追加されます。スケーリングファクター（ドロップされた下位ビットの総数）は、SCALEDTLRまたはSCALEDTLS値です。
For example, say an application has these start and finish timer values (hexadecimal values, in microseconds):
たとえば、アプリケーションに次の開始および終了タイマー値（16進値、マイクロ秒単位）があるとします。
Finish: 27C849234 usec (02:57:58.997556)
-Start: 27C83F696 usec (02:57:58.957718)
========== ============== ==========================
Difference 9B9E usec 0.039838 sec or 39838 usec
To convert this differential value to binary attoseconds, multiply the number of microseconds by 10**12. Divide by 1024**4, or simply discard 40 bits from the right. The result is 36232, or 8D88 in hex, with a scaling factor or SCALEDTLR/SCALEDTLS value of 40.
この差分値をバイナリアト秒に変換するには、マイクロ秒数に10 ** 12を掛けます。 1024 ** 4で除算するか、単純に右から40ビットを破棄します。結果は36232、つまり16進数では8D88で、スケーリング係数またはSCALEDTLR / SCALEDTLS値は40です。
For another example, presume the time differential is larger, say 32.311072 seconds, which is 32311072 usec. Each microsecond is 10**12 asec, so multiply by 10**12, giving the hexadecimal value 1C067FCCAE8120000. Using the initial scaling factor of 40, drop the last 10 characters (40 bits) from that string, giving 1C067FC. This will not fit into a delta field, as it is 25 bits long. Shifting the value to the right another 9 bits results in a delta value of E033, with a resulting scaling factor of 49.
別の例として、時差がより大きく、たとえば32.311072秒、つまり32311072 usecであると仮定します。各マイクロ秒は10 ** 12 asecなので、10 ** 12を掛けて、16進値1C067FCCAE8120000を与えます。初期スケーリング係数40を使用して、最後の10文字（40ビット）をその文字列から削除し、1C067FCを取得します。これは25ビット長なので、デルタフィールドには適合しません。値をさらに9ビット右にシフトすると、デルタ値はE033になり、スケーリング係数は49になります。
When the time-differential value is a small number, regardless of the time unit, the exponent trick given above is not useful in determining the proper scaling value. For example, if the time differential is 3 seconds and you want to convert that directly, you would follow this path:
時間単位に関係なく、時間微分値が小さい場合、上記の指数トリックは適切なスケーリング値を決定するのに役立ちません。たとえば、時差が3秒で、それを直接変換したい場合は、次のパスに従います。
3 seconds = 3*10**18 asec (decimal)
= 29A2241AF62C0000 asec (hexadecimal)
If you just truncate the last 60 bits, you end up with a delta value of 2 and a scaling factor of 60, when what you really wanted was a delta value with more significant digits. The most precision with which you can store this value in 16 bits is A688, with a scaling factor of 46.
最後の60ビットを切り捨てただけの場合は、デルタ値2とスケーリング係数60が得られますが、実際に必要なのは、より重要な桁のデルタ値でした。この値を16ビットで格納できる最も精度の高いのはA688で、倍率は46です。
There are two considerations to be taken into account with this representation of a time differential. The first is whether there are any limitations on the maximum or minimum time differential that can be expressed using the method of a delta value and a scaling factor. The second is the amount of imprecision introduced by this method.
この時間微分の表現に関して考慮すべき2つの考慮事項があります。 1つ目は、デルタ値とスケーリング係数の方法を使用して表現できる最大時間差または最小時間差に制限があるかどうかです。 2つ目は、この方法で導入される不正確さの量です。
The DELTATLS and DELTATLR fields store only the 16 most significant bits of the time-differential value. Thus, the range, excluding the scaling factor, is from 0 to 65535, or a maximum of 2**16 - 1. This method is further described in [TCPM].
DELTATLSおよびDELTATLRフィールドには、時間微分値の上位16ビットのみが格納されます。したがって、スケーリング係数を除いた範囲は0〜65535、または最大2 ** 16-1です。この方法については、[TCPM]で詳しく説明しています。
The actual magnitude of the time differential is determined by the scaling factor. SCALEDTLR and SCALEDTLS are 8-bit unsigned integers, so the scaling factor ranges from 0 to 255. The smallest number that can be represented would have a value of 1 in the delta field and a value of 0 in the associated scale field. This is the representation for 1 attosecond. Clearly, this allows PDM to measure extremely small time differentials.
時間微分の実際の大きさは、倍率によって決まります。 SCALEDTLRおよびSCALEDTLSは8ビットの符号なし整数であるため、スケーリング係数の範囲は0〜255です。表現できる最小の数値は、デルタフィールドの値が1で、関連するスケールフィールドの値が0です。これは1アト秒の表現です。明らかに、これによりPDMは非常に小さな時間差を測定できます。
On the other end of the scale, the maximum delta value is 65535, or FFFF in hexadecimal. If the maximum scale value of 255 is used, the time differential represented is 65535*2**255, which is over 3*10**55 years -- essentially, forever. So, there appears to be no real limitation to the time differential that can be represented.
スケールの反対側では、最大デルタ値は65535、つまり16進数ではFFFFです。 255の最大スケール値が使用される場合、表される時差は65535 * 2 ** 255であり、これは3 * 10 ** 55年を超えます-本質的には永遠です。したがって、表現できる時間微分に実際の制限はないようです。
As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned integers, any time that the precision is greater than those 16 bits, there will be truncation of the trailing bits, with an accompanying loss of precision in the value.
PDMはDELTATLRおよびDELTATLS値を16ビットの符号なし整数として指定するため、精度が16ビットよりも大きい場合は常に、後続ビットが切り捨てられ、値の精度が失われます。
Any time-differential value smaller than 65536 asec can be stored exactly in DELTATLR or DELTATLS, because the representation of this value requires at most 16 bits.
65536 asec未満の時間微分値は、DELTATLRまたはDELTATLSに正確に格納できます。この値の表現には最大で16ビットが必要なためです。
Since the time-differential values in PDM are measured in attoseconds, the range of values that would be truncated to the same encoded value is 2**((Scale) - 1) asec.
PDMの時間微分値はアト秒で測定されるため、同じエンコード値に切り捨てられる値の範囲は2 **（（Scale）-1）asecです。
For example, the smallest time differential that would be truncated to fit into a delta field is
たとえば、デルタフィールドに収まるように切り捨てられる最小の時間差は次のとおりです。
1 0000 0000 0000 0000 = 65536 asec
1 0000 0000 0000 0000 = 65536 asec
This value would be encoded as a delta value of 8000 (hexadecimal) with a scaling factor of 1. The value
この値は、スケーリング係数が1のデルタ値8000（16進数）としてエンコードされます。
1 0000 0000 0000 0001 = 65537 asec
1 0000 0000 0000 0001 = 65537 asec
would also be encoded as a delta value of 8000 with a scaling factor of 1. This actually is the largest value that would be truncated to that same encoded value. When the scale value is 1, the value range is calculated as 2**1 - 1, or 1 asec, which you can see is the difference between these minimum and maximum values.
また、スケーリング係数が1のデルタ値8000としてエンコードされます。これは、実際には、同じエンコードされた値に切り捨てられる最大値です。スケール値が1の場合、値の範囲は2 ** 1-1、または1 asecとして計算されます。これは、これらの最小値と最大値の差であることがわかります。
The scaling factor is defined as the number of low-order bits truncated to reduce the size of the resulting value so it fits into a 16-bit delta field. If, for example, you had to truncate 12 bits, the loss of precision would depend on the bits you truncated. The range of these values would be
スケーリング係数は、結果の値のサイズを小さくして16ビットのデルタフィールドに収まるように切り捨てられた下位ビットの数として定義されます。たとえば、12ビットを切り捨てる必要がある場合、精度の損失は切り捨てたビットによって異なります。これらの値の範囲は
0000 0000 0000 = 0 asec
0000 0000 0000 = 0 asec
to
と
1111 1111 1111 = 4095 asec
1111 1111 1111 = 4095 asec
So, the minimum loss of precision would be 0 asec, where the delta value exactly represents the time differential, and the maximum loss of precision would be 4095 asec. As stated above, the scaling factor of 12 means that the maximum loss of precision is 2**12 - 1 asec, or 4095 asec.
したがって、最小の精度損失は0 asecであり、デルタ値は正確に時間差を表し、最大の精度損失は4095 asecになります。上記のように、12のスケーリング係数は、精度の最大損失が2 ** 12-1 asec、つまり4095 asecであることを意味します。
Compare this loss of precision to the actual time differential. The range of actual time-differential values that would incur this loss of precision is from
この精度の損失を実際の時間差と比較してください。この精度の損失を招く実際の時間微分値の範囲は、
1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec
to
と
1111 1111 1111 1111 1111 1111 1111 = 2**28 - 1 asec or 268435455 asec
Granted, these are small values, but the point is that any value between these two values will have a maximum loss of precision of 4095 asec, or about 0.00305% for the first value, as encoded, and at most 0.001526% for the second. These maximum-loss percentages are consistent for all scaling values.
確かに、これらは小さな値ですが、重要な点は、これらの2つの値の間の値は、最大精度が4095 asec、つまりエンコードされた最初の値が約0.00305％、2番目の値が最大で0.001526％の損失になるということです。これらの最大損失率は、すべてのスケーリング値で一貫しています。
Below is a sample simple flow for PDM with one packet sent from Host A and one packet received by Host B. PDM does not require time synchronization between Host A and Host B. The calculations to derive meaningful metrics for network diagnostics are shown below each packet sent or received.
以下は、ホストAから送信された1つのパケットとホストBによって受信された1つのパケットを使用したPDMの簡単なフローの例です。PDMはホストAとホストB間の時間同期を必要としません。ネットワーク診断の意味のあるメトリックを導き出す計算は、各パケットの下に示されています送信または受信。
Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM.
パケット1がホストAからホストBに送信されます。ホストAの時間は、最初は午前10:00に設定されています。
The time and packet sequence number are saved by the sender internally. The packet sequence number and delta times are sent in the packet.
時間とパケットのシーケンス番号は、送信者によって内部的に保存されます。パケットのシーケンス番号とデルタ時間はパケットで送信されます。
Packet 1
パケット1
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
PDMの内容：
PSNTP : Packet Sequence Number This Packet: 25
PSNLR : Packet Sequence Number Last Received: -
DELTATLR : Delta Time Last Received: -
SCALEDTLR: Scale of Delta Time Last Received: 0
DELTATLS : Delta Time Last Sent: -
SCALEDTLS: Scale of Delta Time Last Sent: 0
Internally, within the sender, Host A, it must keep:
内部的には、送信者であるホストA内で、以下を維持する必要があります。
Packet Sequence Number of the last packet sent: 25
Time the last packet was sent: 10:00:00
Note: The initial PSNTP from Host A starts at a random number -- in this case, 25. The time in these examples is shown in seconds for the sake of simplicity.
注：ホストAからの最初のPSNTPは、乱数（この場合は25）から始まります。これらの例の時間は、簡略化のために秒単位で示されています。
Packet 1 is received at Host B. Its time is set to 1 hour later than Host A -- in this case, 11:00AM.
パケット1はホストBで受信されます。その時間はホストAよりも1時間遅く設定されています。この場合は11:00 AMです。
Internally, within the receiver, Host B, it must note the following:
内部的には、レシーバーであるホストB内で、次のことに注意する必要があります。
Packet Sequence Number of the last packet received: 25
Time the last packet was received : 11:00:03
Note: This timestamp is in Host B time. It has nothing whatsoever to do with Host A time. The packet sequence number of the last packet received will become PSNLR, which will be sent out in the packet sent by Host B in the next step. The timestamp of the packet last received (as noted above) will be used as input to calculate the DELTATLR value to be sent out in the packet sent by Host B in the next step.
注：このタイムスタンプはホストB時間です。ホストAの時間とは何の関係もありません。受信した最後のパケットのパケットシーケンス番号はPSNLRになり、次のステップでホストBが送信したパケットで送信されます。最後に受信したパケットのタイムスタンプ（上記のとおり）は、次のステップでホストBが送信するパケットで送信されるDELTATLR値を計算するための入力として使用されます。
Packet 2 is sent by Host B to Host A. Note that the initial packet sequence number (PSNTP) from Host B starts at a random number -- in this case, 12. Before sending the packet, Host B does a calculation of deltas. Since Host B knows when it is sending the packet and it knows when it received the previous packet, it can do the following calculation:
パケット2はホストBからホストAに送信されます。ホストBからの最初のパケットシーケンス番号（PSNTP）は、乱数（この場合は12）から始まります。パケットを送信する前に、ホストBはデルタの計算を行います。ホストBは、パケットを送信するタイミングと、前のパケットを受信するタイミングを認識しているため、次の計算を実行できます。
DELTATLR = send time (packet 2) - receive time (packet 1)
DELTATLR =送信時間（パケット2）-受信時間（パケット1）
Note: Both the send time and the receive time are saved internally in Host B. They do not travel in the packet. Only the change in values (delta) is in the packet. This is the DELTATLR value.
注：送信時間と受信時間の両方がホストBに内部的に保存されます。これらはパケット内を移動しません。値の変化（デルタ）のみがパケットに含まれます。これは、DELTATLR値です。
Assume that within Host B we have the following:
ホストB内に次のものが存在するとします。
Packet Sequence Number of the last packet received: 25
Time the last packet was received: 11:00:03
Packet Sequence Number of this packet: 12
Time this packet is being sent: 11:00:07
A delta value to be sent out in the packet can now be calculated. DELTATLR becomes:
パケットで送信されるデルタ値を計算できるようになりました。 DELTATLRは次のようになります。
4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec
This is the derived metric: server delay. The time scaling factors must be converted; in this case, the time differential is DE0B, and the scaling factor is 2E, or 46 in decimal. Then, these values, along with the packet sequence numbers, will be sent to Host A as follows:
これは導出されたメトリック、サーバーの遅延です。時間スケーリング係数を変換する必要があります。この場合、時間差はDE0Bであり、スケーリング係数は2E、つまり10進数では46です。次に、これらの値は、パケットシーケンス番号とともに、次のようにホストAに送信されます。
Packet 2
パケット2
+----------+ +----------+
| | | |
| Host | <---------- | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
PDMの内容：
PSNTP : Packet Sequence Number This Packet: 12
PSNLR : Packet Sequence Number Last Received: 25
DELTATLR : Delta Time Last Received: DE0B (4 seconds)
SCALEDTLR: Scale of Delta Time Last Received: 2E (46 decimal)
DELTATLS : Delta Time Last Sent: -
SCALEDTLS: Scale of Delta Time Last Sent: 0
The metric left to be calculated is the round-trip delay. This will be calculated by Host A when it receives packet 2.
計算される残りのメトリックは、往復遅延です。これは、ホストAがパケット2を受信したときに計算されます。
Packet 2 is received at Host A. Remember that its time is set to 1 hour earlier than Host B. Internally, it must note the following:
パケット2はホストAで受信されます。その時間はホストBよりも1時間早く設定されていることに注意してください。内部的には、次の点に注意する必要があります。
Packet Sequence Number of the last packet received: 12
Time the last packet was received : 10:00:12
Note: This timestamp is in Host A time. It has nothing whatsoever to do with Host B time.
注：このタイムスタンプはホストAの時間です。ホストBの時間とは何の関係もありません。
So, Host A can now calculate total end-to-end time. That is:
したがって、ホストAは、エンドツーエンドの合計時間を計算できるようになりました。あれは：
End-to-End Time = Time Last Received - Time Last Sent
エンドツーエンド時間=最後に受信された時間-最後に送信された時間
For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was received by Host A at 10:00:12, so:
たとえば、パケット25はホストAによって10:00:00に送信されました。パケット12は10:00:12にホストAが受信したので、
End-to-End time = 10:00:12 - 10:00:00 or 12 (server and network round-trip delay combined).
エンドツーエンド時間= 10:00:12-10:00:00または12（サーバーとネットワークの往復遅延の合計）。
This time may also be called "total overall Round-Trip Time (RTT)", which includes network RTT and host response time.
この時間は「ネットワーク全体のラウンドトリップ時間（RTT）の合計」とも呼ばれ、ネットワークRTTとホストの応答時間を含みます。
We will call this derived metric "Delta Time Last Sent" (DELTATLS).
この派生メトリックを "Delta Time Last Sent"（DELTATLS）と呼びます。
Round-trip delay can now be calculated. The formula is:
往復遅延を計算できるようになりました。式は次のとおりです。
Round-trip delay = (Delta Time Last Sent - Delta Time Last Received)
往復遅延=（最後に送信されたデルタ時間-最後に受信されたデルタ時間）
Or:
または：
Round-trip delay = 12 - 4 or 8
往復遅延= 12-4または8
At this point, the only problem is that all metrics are in Host A only and not exposed in a packet. To do that, we need a third packet.
この時点での唯一の問題は、すべてのメトリックがホストAにのみ存在し、パケットに公開されないことです。そのためには、3番目のパケットが必要です。
Note: This simple example assumes one send and one receive. That is done only for purposes of explaining the function of PDM. In cases where there are multiple packets returned, one would take the time in the last packet in the sequence. The calculations of such timings and intelligent processing are the function of post-processing of the data.
注：この簡単な例では、1つの送信と1つの受信を想定しています。これは、PDMの機能を説明する目的でのみ行われます。複数のパケットが返された場合、シーケンスの最後のパケットで時間がかかります。このようなタイミングの計算とインテリジェントな処理は、データの後処理の機能です。
Packet 3 is sent from Host A to Host B.
パケット3はホストAからホストBに送信されます。
+----------+ +----------+
| | | |
| Host | ----------> | Host |
| A | | B |
| | | |
+----------+ +----------+
PDM Contents:
PDMの内容：
PSNTP : Packet Sequence Number This Packet: 26
PSNLR : Packet Sequence Number Last Received: 12
DELTATLR : Delta Time Last Received: 0
SCALEDTLS: Scale of Delta Time Last Received 0
DELTATLS : Delta Time Last Sent: A688 (scaled value)
SCALEDTLR: Scale of Delta Time Last Received: 30 (48 decimal)
To calculate two-way delay, any packet-capture device may look at these packets and do what is necessary.
双方向遅延を計算するために、パケットキャプチャデバイスはこれらのパケットを調べて、必要な処理を実行します。
What has been discussed so far is a simple flow with one packet sent and one returned. Let's look at how PDM may be useful in other types of flows.
これまで説明してきたのは、1つのパケットが送信され、1つのパケットが返される単純なフローです。 PDMが他のタイプのフローでどのように役立つかを見てみましょう。
The flow on a particular session may not be a send-receive paradigm. Let us consider some other situations. In the case of a one-way flow, one might see the following.
特定のセッションのフローは、送受信パラダイムではない場合があります。他のいくつかの状況を考えてみましょう。一方向のフローの場合、次のようになります。
Note: The time is expressed in generic units for simplicity. That is, these values do not represent a number of attoseconds, microseconds, or any other real units of time.
注：時間は単純化するために一般的な単位で表されます。つまり、これらの値は、アト秒、マイクロ秒、またはその他の実際の時間単位を表していません。
Packet Sender PSN PSN Delta Time Delta Time
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Server 3 0 0 12
4 Server 4 0 0 20
What does this mean, and how is it useful?
In a one-way flow, only the Delta Time Last Sent will be seen as used. Recall that Delta Time Last Sent is the difference between the send of one packet from a device and the next. This is a measure of throughput for the sender -- according to the sender's point of view. That is, it is a measure of how fast the application itself (with stack time included) is able to send packets.
一方向のフローでは、最後に送信されたデルタ時間のみが使用済みとして表示されます。 Delta Time Last Sentは、デバイスからの1つのパケットの送信と次のパケットの送信の差であることを思い出してください。これは、送信者の観点による、送信者のスループットの測定値です。つまり、アプリケーション自体（スタック時間を含む）がパケットを送信できる速度の目安です。
How might this be useful? If one is having a performance issue at the client and sees that packet 2, for example, is sent after 5 time units from the server but takes 10 times that long to arrive at the destination, then one may safely conclude that there are delays in the path, other than at the server, that may be causing the delivery issue for that packet. Such delays may include the network links, middleboxes, etc.
これはどのように役立ちますか？たとえば、クライアントでパフォーマンスの問題が発生していて、パケット2がサーバーから5時間単位後に送信されたにもかかわらず、宛先に到着するまでに10倍の時間がかかる場合、遅延が発生していると安全に結論付けることができます。そのパケットの配信問題を引き起こしている可能性のある、サーバー以外のパス。このような遅延には、ネットワークリンク、ミドルボックスなどが含まれます。
True one-way traffic is quite rare. What people often mean by "one-way" traffic is an application such as FTP where a group of packets (for example, a TCP window size worth) is sent and the sender then waits for acknowledgment. This type of flow would actually fall into the "multiple-send" traffic model.
真の一方通行は非常にまれです。人々が「一方向」のトラフィックでしばしば意味するのは、パケットのグループ（たとえば、TCPウィンドウサイズに相当）が送信され、送信者が確認を待つFTPなどのアプリケーションです。このタイプのフローは、実際には「複数送信」トラフィックモデルに分類されます。
Assume that two packets are sent from the server and then an ACK is sent from the client. For example, a TCP flow will do this, per RFC 1122 [RFC1122], Section 4.2.3. Packets 1 and 2 are sent from the server, and then an ACK is sent from the client. Packet 4 starts a second sequence from the server.
サーバーから2つのパケットが送信され、クライアントからACKが送信されたとします。たとえば、TCPフローは、RFC 1122 [RFC1122]のセクション4.2.3に従ってこれを行います。パケット1と2はサーバーから送信され、次にACKがクライアントから送信されます。パケット4は、サーバーから2番目のシーケンスを開始します。
Packet Sender PSN PSN Delta Time Delta Time
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Client 1 2 20 0
4 Server 3 1 10 15
How might this be used?
これはどのように使用できますか？
Notice that in packet 3, the client has a Delta Time Last Received value of 20. Recall that:
パケット3では、クライアントのDelta Time Last Received値が20であることに注意してください。
DELTATLR = send time (packet 3) - receive time (packet 2)
DELTATLR =送信時間（パケット3）-受信時間（パケット2）
So, what does one know now? In this case, Delta Time Last Received is the processing time for the client to send the next packet.
それで、今、何を知っていますか？この場合、Delta Time Last Receivedは、クライアントが次のパケットを送信するための処理時間です。
How to interpret this depends on what is actually being sent. Remember that PDM is not being used in isolation; rather, it is used to supplement the fields found in other headers. Let's take two examples:
これをどのように解釈するかは、実際に送信されているものによって異なります。 PDMは単独で使用されていないことに注意してください。むしろ、他のヘッダーにあるフィールドを補足するために使用されます。 2つの例を見てみましょう。
1. The client is sending a standalone TCP ACK. One would find this by looking at the payload length in the IPv6 header and the TCP Acknowledgment field in the TCP header. So, in this case, the client is taking 20 time units to send back the ACK. This may or may not be interesting.
1. クライアントがスタンドアロンTCP ACKを送信しています。これは、IPv6ヘッダーのペイロード長とTCPヘッダーのTCP確認応答フィールドを見ればわかります。したがって、この場合、クライアントは20時間単位でACKを返信しています。これは興味深い場合とそうでない場合があります。
2. The client is sending data with the packet. Again, one would find this by looking at the payload length in the IPv6 header and the TCP Acknowledgment field in the TCP header. So, in this case, the client is taking 20 time units to send back data. This may represent "User Think Time". Again, this may or may not be interesting in isolation. But if there is a performance problem receiving data at the server, then, taken in conjunction with RTT or other packet timing information, this information may be quite interesting.
2. クライアントはパケットと共にデータを送信しています。この場合も、IPv6ヘッダーのペイロード長とTCPヘッダーのTCP確認応答フィールドを見れば、これがわかります。したがって、この場合、クライアントはデータを返信するために20時間単位を使用しています。これは「ユーザー思考時間」を表す場合があります。繰り返しになりますが、これは単独では興味深い場合とそうでない場合があります。しかし、サーバーでデータを受信する際にパフォーマンスの問題がある場合、RTTまたはその他のパケットタイミング情報と併せて使用すると、この情報は非常に興味深いものになる可能性があります。
Of course, one also needs to look at the PSN Last Received field to make sure of the interpretation of this data -- that is, to make sure that the Delta Time Last Received corresponds to the packet of interest.
もちろん、PSN Last Receivedフィールドを見て、このデータの解釈を確認する必要もあります。つまり、Delta Time Last Receivedが対象のパケットに対応していることを確認する必要があります。
The benefits of PDM are that such information is now available in a uniform manner for all applications and all protocols without extensive changes required to applications.
PDMの利点は、そのような情報が、アプリケーションに大幅な変更を加えることなく、すべてのアプリケーションとすべてのプロトコルで統一された方法で利用できることです。
Let us now look at a case of how PDM may be able to help in a case of TCP retransmission and add to the information that is sent in the TCP header.
次に、TCP再送信の場合にPDMがどのように役立つかを見て、TCPヘッダーで送信される情報に追加します。
Assume that three packets are sent with each send from the server.
サーバーからの送信ごとに3つのパケットが送信されると想定します。
From the server, this is what is seen:
サーバーから、これは見られるものです：
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 2 0 0 5 223 100
3 Server 3 0 0 5 333 100
The client, however, does not receive all the packets. From the
client, this is what is seen for the packets sent from the server:
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 3 0 0 5 333 100
Let's assume that the server now retransmits the packet. (Obviously, a duplicate acknowledgment sequence for fast retransmit or a retransmit timeout would occur. To illustrate the point, these packets are being left out.)
サーバーがパケットを再送信するとします。 （明らかに、高速再送信または再送信タイムアウトの重複した確認応答シーケンスが発生します。要点を説明するために、これらのパケットは省略されています。）
So, if a TCP retransmission is done, then from the client, this is what is seen for the packets sent from the server:
したがって、TCP再送信が行われた場合、クライアントからは、サーバーから送信されたパケットに対して次のようになります。
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
=====================================================================
1 Server 4 0 0 30 223 100
The server has resent the old packet 2 with a TCP sequence number of 223. The retransmitted packet now has a PSN This Packet value of 4.
サーバーは、TCPシーケンス番号が223の古いパケット2を再送信しました。再送信されたパケットのPSN This Packet値は4です。
The Delta Time Last Sent is 30 -- in other words, the time between sending the packet with a PSN of 3 and this current packet.
最後に送信されたデルタ時間は30-つまり、PSNが3のパケットを送信してから現在のパケットが送信されるまでの時間です。
Let's say that packet 4 is lost again. Then, after some amount of time (RTO), the packet with a TCP sequence number of 223 is resent.
パケット4が再び失われたとしましょう。次に、一定の時間（RTO）が経過すると、TCPシーケンス番号が223のパケットが再送信されます。
From the client, this is what is seen for the packets sent from the server:
クライアントから、これはサーバーから送信されたパケットのために見られるものです：
Pkt Sender PSN PSN Delta Time Delta Time TCP Data
This Pkt Last Recvd Last Recvd Last Sent SEQ Bytes
====================================================================
1 Server 5 0 0 60 223 100
If this packet now arrives at the destination, one has a very good idea that packets exist that are being sent from the server as retransmissions and not arriving at the client. This is because the PSN of the resent packet from the server is 5 rather than 4. If we had used the TCP sequence number alone, we would never have seen this situation. The TCP sequence number in all situations is 223.
このパケットが宛先に到着した場合、再送信としてサーバーから送信されており、クライアントに到着していないパケットが存在するという非常に良い考えがあります。これは、サーバーからの再送信パケットのPSNが4ではなく5であるためです。TCPシーケンス番号だけを使用した場合、このような状況は発生しません。すべての状況でのTCPシーケンス番号は223です。
This situation would be experienced by the user of the application (the human being actually sitting somewhere) as "hangs" or long delays between packets. On large networks, to diagnose problems such as these where packets are lost somewhere on the network, one has to take multiple traces to find out exactly where.
この状況は、アプリケーションのユーザー（実際にはどこかに座っている人間）がパケット間の「ハング」または長い遅延として経験することになります。大規模なネットワークでは、ネットワーク上のどこかでパケットが失われるなどの問題を診断するには、複数のトレースを実行して正確な場所を見つける必要があります。
The first thing to do is to start with doing a trace at the client and the server, so that we can see if the server sent a particular packet and the client received it. If the client did not receive it, then we start tracking back to trace points at the router right after the server and the router right before the client. Did they get these packets that the server has sent? This is a time-consuming activity.
最初にすることは、クライアントとサーバーでトレースを開始することです。これにより、サーバーが特定のパケットを送信し、クライアントがそれを受信したかどうかを確認できます。クライアントがそれを受信しなかった場合は、サーバーの直後のルーターとクライアントの直前のルーターでトレースポイントへの追跡を開始します。彼らはサーバーが送信したこれらのパケットを受け取りましたか？これは時間のかかる作業です。
With PDM, we can speed up the diagnostic time because we may be able to use only the trace taken at the client to see what the server is sending.
PDMを使用すると、サーバーで送信されているものを確認するためにクライアントで取得されたトレースのみを使用できる場合があるため、診断時間を短縮できます。
One might wonder about the potential overhead of PDM. First, PDM is entirely optional. That is, a site may choose to implement PDM or not, as they wish. If they are happy with the costs of PDM versus the benefits, then the choice should be theirs.
PDMの潜在的なオーバーヘッドについて疑問に思うかもしれません。まず、PDMは完全にオプションです。つまり、サイトはPDMを実装するかどうかを希望どおりに選択できます。彼らがPDMのコストと利点に満足している場合、選択は彼らのものでなければなりません。
Below is a table outlining the potential overhead in terms of additional time to deliver the response to the end user for various assumed RTTs:
以下の表は、想定されるさまざまなRTTに対してエンドユーザーに応答を提供するための追加時間に関する潜在的なオーバーヘッドの概要を示しています。
Bytes RTT Bytes Bytes New Overhead
in Packet Per Millisec in PDM RTT
====================================================================
1000 1000 milli 1 16 1016.000 16.000 milli
1000 100 milli 10 16 101.600 1.600 milli
1000 10 milli 100 16 10.160 0.160 milli
1000 1 milli 1000 16 1.016 0.016 milli
Below are two examples of actual RTTs for packets traversing large enterprise networks.
以下は、大規模なエンタープライズネットワークを通過するパケットの実際のRTTの2つの例です。
The first example is for packets going to multiple business partners:
最初の例は、複数のビジネスパートナーに送信されるパケットの場合です。
Bytes RTT Bytes Bytes New Overhead
in Packet Per Millisec in PDM RTT
====================================================================
1000 17 milli 58 16 17.360 0.360 milli
The second example is for packets at a large enterprise customer
within a data center. Notice that the scale is now in microseconds
rather than milliseconds:
Bytes RTT Bytes Bytes New Overhead
in Packet Per Microsec in PDM RTT
====================================================================
1000 20 micro 50 16 20.320 0.320 micro
As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM. Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal.
パケットトレースなどの他の診断ツールと同様に、PDMを作成して処理するには、ある程度の処理時間が必要です。 PDMは軽量であるため（変数の数が少ない）、処理時間が最小限になると予想されます。
Acknowledgments
謝辞
The authors would like to thank Keven Haining, Al Morton, Brian Trammell, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick Troth for their comments and assistance. We would also like to thank Tero Kivinen and Jouni Korhonen for their detailed and perceptive reviews.
著者は、Keven Haining、Al Morton、Brian Trammell、David Boyes、Bill Jouris、Richard Scheffenegger、およびRick Trothのコメントと支援に感謝します。また、Tero KivinenとJouni Korhonenの詳細で知覚的なレビューに感謝します。
Authors' Addresses
著者のアドレス
Nalini Elkins Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States of America
Nalini Elkins Inside Products、Inc. 36A Upper Circle Carmel Valley、CA 93924アメリカ合衆国
Phone: +1 831 659 8360
Email: nalini.elkins@insidethestack.com
URI: http://www.insidethestack.com
Robert M. Hamilton Chemical Abstracts Service A Division of the American Chemical Society 2540 Olentangy River Road Columbus, Ohio 43202 United States of America
ロバートM.ハミルトンケミカルアブストラクツサービスアメリカ化学協会の部2540 Olentangy River Roadコロンバス、オハイオ43202アメリカ合衆国
Phone: +1 614 447 3600 x2517
Email: rhamilton@cas.org
URI: http://www.cas.org
Michael S. Ackermann Blue Cross Blue Shield of Michigan P.O. Box 2888 Detroit, Michigan 48231 United States of America
マイケルS.アッカーマンブルークロスミシガンP.O.のブルーシールドBox 2888デトロイト、ミシガン48231アメリカ合衆国
Phone: +1 310 460 4080
Email: mackermann@bcbsm.com
URI: http://www.bcbsm.com