[要約] この文書では、クライアントとサーバー間のトランスポート層プロトコルに適用可能なプロトコル非依存の手法である「明示的ホスト対ネットワークフロー測定技術」について説明しています。これらの手法は、パフォーマンス測定のために各パケットのヘッダ内にわずかなマーキングビットを使用し、クライアントとサーバーが協力する必要があります。これらの技術は、トランスポートヘッダを暗号化するプロトコルに適用されると特に価値があり、パッシブで経路上のネットワークデバイスによる損失と遅延の測定を可能にします。この文書では、マーキングビットの可用性、希望する測定、および適用されるプロトコルの特性に応じて、個別または共同で使用できるいくつかの方法について説明しています。
Internet Engineering Task Force (IETF) M. Cociglio
Request for Comments: 9506 Telecom Italia - TIM
Category: Informational A. Ferrieux
ISSN: 2070-1721 Orange Labs
G. Fioccola
Huawei Technologies
I. Lubashev
Akamai Technologies
F. Bulgarella
M. Nilo
Telecom Italia - TIM
I. Hamchaoui
Orange Labs
R. Sisto
Politecnico di Torino
October 2023
This document describes protocol-independent methods called Explicit Host-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between the client and server. These methods employ just a few marking bits inside the header of each packet for performance measurements and require the client and server to collaborate. Both endpoints cooperate by marking packets and, possibly, mirroring the markings on the round-trip connection. The techniques are especially valuable when applied to protocols that encrypt transport headers since they enable loss and delay measurements by passive, on-path network devices. This document describes several methods that can be used separately or jointly depending of the availability of marking bits, desired measurements, and properties of the protocol to which the methods are applied.
このドキュメントは、クライアントとサーバーの間の輸送層プロトコルに適用できる明示的なホストからネットワークへのフロー測定技術と呼ばれるプロトコル非依存の方法について説明します。これらの方法では、パフォーマンス測定のために各パケットのヘッダー内にいくつかのマーキングビットを使用しており、クライアントとサーバーがコラボレーションする必要があります。両方のエンドポイントは、パケットをマークし、おそらく往復接続のマーキングをミラーリングすることにより協力します。手法は、パッシブオンパスネットワークデバイスによる損失および遅延測定を可能にするため、トランスポートヘッダーを暗号化するプロトコルに適用する場合、特に価値があります。このドキュメントでは、マークビットの可用性、望ましい測定値、およびメソッドが適用されるプロトコルのプロパティに応じて、個別にまたは共同で使用できるいくつかの方法について説明します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9506.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9506で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Latency Bits
2.1. Spin Bit
2.2. Delay Bit
2.2.1. Generation Phase
2.2.2. Reflection Phase
2.2.3. T_Max Selection
2.2.4. Delay Measurement Using the Delay Bit
2.2.4.1. RTT Measurement
2.2.4.2. Half-RTT Measurement
2.2.4.3. Intra-domain RTT Measurement
2.2.5. Observer's Algorithm
2.2.6. Two Bits Delay Measurement: Spin Bit + Delay Bit
3. Loss Bits
3.1. T Bit -- Round-Trip Loss Bit
3.1.1. Round-Trip Loss
3.1.2. Setting the Round-Trip Loss Bit on Outgoing Packets
3.1.3. Observer's Logic for Round-Trip Loss Signal
3.1.4. Loss Coverage and Signal Timing
3.2. Q Bit -- sQuare Bit
3.2.1. Q Block Length Selection
3.2.2. Upstream Loss
3.2.3. Identifying Q Block Boundaries
3.2.3.1. Improved Resilience to Burst Losses
3.3. L Bit -- Loss Event Bit
3.3.1. End-To-End Loss
3.3.1.1. Loss Profile Characterization
3.3.2. L+Q Bits -- Loss Measurement Using L and Q Bits
3.3.2.1. Correlating End-to-End and Upstream Loss
3.3.2.2. Downstream Loss
3.3.2.3. Observer Loss
3.4. R Bit -- Reflection Square Bit
3.4.1. Enhancement of Reflection Block Length Computation
3.4.2. Improved Resilience to Packet Reordering
3.4.2.1. Improved Resilience to Burst Losses
3.4.3. R+Q Bits -- Loss Measurement Using R and Q Bits
3.4.3.1. Three-Quarters Connection Loss
3.4.3.2. End-To-End Loss in the Opposite Direction
3.4.3.3. Half Round-Trip Loss
3.4.3.4. Downstream Loss
3.5. E Bit -- ECN-Echo Event Bit
3.5.1. Setting the ECN-Echo Event Bit on Outgoing Packets
3.5.2. Using E Bit for Passive ECN-Reported Congestion
Measurement
3.5.3. Multiple E Bits
4. Summary of Delay and Loss Marking Methods
4.1. Implementation Considerations
5. Examples of Application
6. Protocol Ossification Considerations
7. Security Considerations
7.1. Optimistic ACK Attack
7.2. Delay Bit with RTT Obfuscation
8. Privacy Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Packet loss and delay are hard and pervasive problems of day-to-day network operation. Proactively detecting, measuring, and locating them is crucial to maintaining high QoS and timely resolution of end-to-end throughput issues.
パケットの損失と遅延は、日々のネットワーク操作の困難で広範な問題です。それらを積極的に検出、測定、および特定することは、高いQOを維持し、エンドツーエンドのスループットの問題をタイムリーに解決するために重要です。
Detecting and measuring packet loss and delay allows network operators to independently confirm trouble reports and, ideally, be proactively notified of developing problems on the network. Locating the cause of packet loss or excessive delay is the first step to resolving problems and restoring QoS.
パケットの損失と遅延を検出および測定することで、ネットワークオペレーターはトラブルレポートを独立して確認し、理想的にはネットワーク上の問題の発生を積極的に通知することができます。パケットの損失または過度の遅延の原因を見つけることは、問題を解決し、QOを復元するための最初のステップです。
Network operators wishing to perform quantitative measurement of packet loss and delay have been heavily relying on information present in the clear in transport-layer headers (e.g., TCP sequence and acknowledgment numbers). By passively observing a network path at multiple points within one's network, operators have been able to either quickly locate the source the problem within their network or reliably attribute it to an upstream or downstream network.
パケットの損失と遅延の定量的測定を希望するネットワークオペレーターは、輸送層ヘッダーの明確な情報（TCPシーケンスや確認番号など）に存在する情報に大きく依存しています。ネットワーク内の複数のポイントでネットワークパスを受動的に観察することにより、オペレーターはネットワーク内の問題を迅速に見つけるか、それを上流または下流のネットワークに確実に属性することができました。
With encrypted protocols, the transport-layer headers are encrypted and passive packet loss and delay observations are not possible, as also noted in [TRANSPORT-ENCRYPT]. Nevertheless, accurate measurement of packet loss and delay experienced by encrypted transport-layer protocols is highly desired, especially by network operators who own or control the infrastructure between the client and server.
暗号化されたプロトコルを使用すると、輸送層ヘッダーは暗号化されており、[輸送エンクリプト]にも記載されているように、パケットパケットの損失と遅延観測は不可能です。それにもかかわらず、暗号化された輸送層プロトコルが経験するパケット損失と遅延の正確な測定は、特にクライアントとサーバー間のインフラストラクチャを所有または制御するネットワークオペレーターによって非常に望まれます。
The measurement of loss and delay experienced by connections using an encrypted protocol cannot be based on a measurement of loss and delay experienced by connections between the same or similar endpoints that use an unencrypted protocol because different protocols may utilize the network differently and be routed differently by the network. Therefore, it is necessary to directly measure the packet loss and delay experienced by users of encrypted protocols.
暗号化されたプロトコルを使用して接続が経験した損失と遅延の測定は、異なるプロトコルがネットワークを異なる方法で利用し、異なるルーティングを行う可能性があるため、暗号化されていないプロトコルを使用する同じまたは同様のエンドポイント間の接続によって経験される損失と遅延の測定に基づくことはできません。ネットワーク。したがって、暗号化されたプロトコルのユーザーが経験するパケットの損失と遅延を直接測定する必要があります。
The Alternate-Marking method [AltMark] defines a consolidated method to perform packet loss, delay, and jitter measurements on live traffic. However, as mentioned in [IPv6AltMark], [AltMark] mainly applies to a network-layer-controlled domain managed with a Network Management System (NMS), where the Customer Premises Equipment (CPE) or the Provider Edge (PE) routers are the starting or the ending nodes. [AltMark] provides measurement within a controlled domain in which the packets are marked. Therefore, applying [AltMark] to end-to-end transport-layer connections is not easy because packet identification and marking by network nodes is prevented when encrypted transport-layer headers (e.g., QUIC, TCP with TLS) are being used.
代替マーキング方法[Altmark]は、ライブトラフィックでパケットの損失、遅延、およびジッター測定を実行する統合方法を定義します。ただし、[IPv6Altmark]で述べたように、[Altmark]は主にネットワーク管理システム（NMS）で管理されているネットワークレイヤー制御ドメインに適用されます。開始または終了ノード。[Altmark]は、パケットがマークされている制御ドメイン内で測定を提供します。したがって、暗号化された輸送層ヘッダー（例：QUIC、TCPを使用したTCPなど）が使用されている場合、ネットワークノードによるパケットの識別とマーキングが防止されるため、エンドツーエンドの輸送層接続に[altmark]を適用することは容易ではありません。
This document defines Explicit Host-to-Network Flow Measurement Techniques that are specifically designed for encrypted transport protocols. According to the definitions of [IPPM-METHODS], these measurement methods can be classified as Hybrid. They are to be embedded into a transport-layer protocol and are explicitly intended for exposing delay and loss rate information to on-path measurement devices. Unlike [AltMark], most of these methods require collaborative endpoint nodes. Since these measurement techniques make performance information directly visible to the path, they do not rely on an external NMS.
このドキュメントでは、暗号化された輸送プロトコル用に特別に設計された明示的なホストからネットワークへのフロー測定技術を定義します。[IPPM-Methods]の定義によれば、これらの測定方法はハイブリッドとして分類できます。それらは輸送層プロトコルに埋め込まれ、遅延および損失率情報をオンパス測定デバイスに公開することを明示的に意図しています。[altmark]とは異なり、これらの方法のほとんどは共同エンドポイントノードを必要とします。これらの測定技術により、パフォーマンス情報がパスに直接表示されるため、外部NMSに依存しません。
The Explicit Host-to-Network Flow Measurement Techniques described in this document are applicable to any transport-layer protocol connecting a client and a server. In this document, the client and the server are also referred to as the endpoints of the transport-layer protocol.
このドキュメントで説明されている明示的なホストからネットワークへのフロー測定技術は、クライアントとサーバーを接続する輸送レイヤープロトコルに適用できます。このドキュメントでは、クライアントとサーバーも輸送層プロトコルのエンドポイントとも呼ばれます。
The different methods described in this document can be used alone or in combination. Each technique uses few bits and exposes a specific measurement. It is assumed that the endpoints are collaborative in the sense of the measurements, indeed both the client and server need to cooperate.
このドキュメントで説明されているさまざまな方法は、単独でまたは組み合わせて使用できます。各手法は少数のビットを使用し、特定の測定を公開します。エンドポイントは測定の意味で共同であり、実際にクライアントとサーバーの両方が協力する必要があると想定されています。
Following the recommendation in [RFC8558] of making path signals explicit, this document proposes adding some dedicated measurement bits to the clear portion of the transport protocol headers. These bits can be added to an unencrypted portion of a transport-layer header, e.g., UDP surplus space (see [UDP-OPTIONS] and [UDP-SURPLUS]) or reserved bits in a QUIC v1 header, as already done with the latency Spin bit (see Section 17.4 of [QUIC-TRANSPORT]). Note that this document does not recommend the use of any specific bits, as these would need to be chosen by the specific protocol implementations (see Section 5).
[RFC8558]のパス信号を明示的に作成するという推奨に続いて、このドキュメントは、輸送プロトコルヘッダーのクリア部分にいくつかの専用測定ビットを追加することを提案しています。これらのビットは、輸送層ヘッダーの暗号化されていない部分、たとえばUDP余剰スペース（[UDPオプション]および[UDP-Surplus]を参照）を参照）またはQUIC V1ヘッダーの予約ビットに追加できます。スピンビット（[quic-transport]のセクション17.4を参照）。このドキュメントは、特定のプロトコルの実装によって選択する必要があるため、特定のビットの使用を推奨していないことに注意してください（セクション5を参照）。
The Spin bit, Delay bit, and loss bits explained in this document are inspired by [AltMark], [QUIC-MANAGEABILITY], [QUIC-SPIN], [TSVWG-SPIN], and [IPPM-SPIN].
このドキュメントで説明されているスピンビット、遅延ビット、および損失ビットは、[altmark]、[quic-manageability]、[quic-spin]、[tsvwg-spin]、および[ippm-spin]に触発されています。
Additional details about the performance measurements for QUIC are described in the paper [ANRW19-PM-QUIC].
QUICのパフォーマンス測定に関する追加の詳細については、論文[ANRW19-PM-Quic]に記載されています。
This section introduces bits that can be used for round-trip latency measurements. Whenever this section of the specification refers to packets, it is referring only to packets with protocol headers that include the latency bits.
このセクションでは、往復レイテンシ測定に使用できるビットを紹介します。仕様のこのセクションがパケットを指すたびに、それはレイテンシビットを含むプロトコルヘッダーを持つパケットのみを参照しています。
In [QUIC-TRANSPORT], Section 17.4 introduces an explicit, per-flow transport-layer signal for hybrid measurement of RTT. This signal consists of a Spin bit that toggles once per RTT. Section 4 of [QUIC-SPIN] discusses an additional two-bit Valid Edge Counter (VEC) to compensate for loss and reordering of the Spin bit and to increase fidelity of the signal in less than ideal network conditions.
[Quic-Transport]では、セクション17.4では、RTTのハイブリッド測定のための明示的で流量あたりの輸送層信号を導入します。この信号は、RTTごとに1回切り替えるスピンビットで構成されています。[Quic-Spin]のセクション4では、追加の2ビット有効なエッジカウンター（VEC）について説明し、スピンビットの損失と並べ替えを補償し、理想的なネットワーク条件よりも低い信号の忠実度を高めます。
This document introduces a standalone single-bit delay signal that can be used by passive observers to measure the RTT of a network flow, avoiding the Spin bit ambiguities that arise as soon as network conditions deteriorate.
このドキュメントでは、パッシブオブザーバーがネットワークフローのRTTを測定するために使用できるスタンドアロンの単一ビット遅延信号を導入し、ネットワーク条件が悪化するとすぐに発生するスピンビットのあいまいさを回避します。
This section is a small recap of the Spin bit working mechanism. For a comprehensive explanation of the algorithm, see Section 3.8.2 of [QUIC-MANAGEABILITY].
このセクションは、スピンビット作業メカニズムの小さな要約です。アルゴリズムの包括的な説明については、[Quic-Manageability]のセクション3.8.2を参照してください。
The Spin bit is a signal generated by Alternate-Marking [AltMark], where the size of the alternation changes with the flight size each RTT.
スピンビットは、Alternate-Marking [Altmark]によって生成される信号です。このサイズは、各RTTのフライトサイズとともに変化します。
The latency Spin bit is a single-bit signal that toggles once per RTT, enabling latency monitoring of a connection-oriented communication from intermediate observation points.
Latencyスピンビットは、RTTごとに1回切り替える単一ビット信号であり、中間観測点からの接続指向の通信のレイテンシモニタリングを可能にします。
A "Spin bit period" is a set of packets with the same Spin bit value sent during one RTT time interval. A "Spin bit period value" is the value of the Spin bit shared by all packets in a Spin bit period.
「スピンビット期間」は、1つのRTT時間間隔で送信される同じスピンビット値を持つパケットのセットです。「スピンビット期間値」は、スピンビット期間にすべてのパケットで共有されるスピンビットの値です。
The client and server maintain an internal per-connection spin value (i.e., 0 or 1) used to set the Spin bit on outgoing packets. Both endpoints initialize the spin value to 0 when a new connection starts. Then:
クライアントとサーバーは、発信パケットにスピンビットを設定するために使用される内部ごとの接続ごとのスピン値（つまり、0または1）を維持します。両方のエンドポイントは、新しい接続が開始されたときにスピン値を0に初期化します。それから：
* when the client receives a packet with the packet number larger than any number seen so far, it sets the connection spin value to the opposite value contained in the received packet; and
* クライアントがこれまでに見た任意の数よりも大きいパケット番号を持つパケットを受信すると、接続スピン値を受信パケットに含まれる逆の値に設定します。そして
* when the server receives a packet with the packet number larger than any number seen so far, it sets the connection spin value to the same value contained in the received packet.
* サーバーがこれまでに見た任意の数よりも大きいパケット番号を持つパケットを受信すると、接続スピン値を受信パケットに含まれる同じ値に設定します。
The computed spin value is used by the endpoints for setting the Spin bit on outgoing packets. This mechanism allows the endpoints to generate a square wave such that, by measuring the distance in time between pairs of consecutive edges observed in the same direction, a passive on-path observer can compute the round-trip network delay of that network flow.
計算されたスピン値は、発信パケットにスピンビットを設定するためにエンドポイントによって使用されます。このメカニズムにより、エンドポイントは正方形の波を生成することができ、同じ方向に観測された連続したエッジのペア間の時間の距離を測定することにより、パッシブオンパスオブザーバーはそのネットワークフローの往復ネットワーク遅延を計算できます。
Spin bit enables round-trip latency measurement by observing a single direction of the traffic flow.
スピンビットは、トラフィックフローの単一の方向を観察することにより、往復レイテンシ測定を可能にします。
Note that packet reordering can cause spurious edges that require heuristics to correct. The Spin bit performance deteriorates as soon as network impairments arise as explained in Section 2.2.
パケットの並べ替えは、ヒューリスティックを修正する必要がある偽のエッジを引き起こす可能性があることに注意してください。セクション2.2で説明されているように、ネットワーク障害が発生するとすぐに、スピンビットのパフォーマンスが悪化します。
The Delay bit has been designed to overcome accuracy limitations experienced by the Spin bit under difficult network conditions:
遅延ビットは、困難なネットワーク条件下でスピンビットが経験する精度の制限を克服するように設計されています。
* packet reordering leads to generation of spurious edges and errors in delay estimation;
* パケットの並べ替えは、遅延推定でスプリアスエッジの生成とエラーにつながります。
* loss of edges causes wrong estimation of Spin bit periods and therefore wrong RTT measurements; and
* エッジの損失は、スピンビット期間の誤った推定を引き起こすため、RTT測定が誤っています。そして
* application-limited senders cause the Spin bit to measure the application delays instead of network delays.
* アプリケーションに制限された送信者は、ネットワークの遅延の代わりにスピンビットをアプリケーションの遅延を測定します。
Unlike the Spin bit, which is set in every packet transmitted on the network, the Delay bit is set only once per round trip.
ネットワーク上に送信されるすべてのパケットで設定されているスピンビットとは異なり、遅延ビットは往復ごとに1回だけ設定されます。
When the Delay bit is used, a single packet with a marked bit (the Delay bit) bounces between a client and a server during the entire connection lifetime. This single packet is called the "delay sample".
遅延ビットを使用すると、マークされたビット（遅延ビット）を備えた単一のパケットが、接続寿命全体でクライアントとサーバーの間で跳ね返ります。この単一のパケットは、「遅延サンプル」と呼ばれます。
An observer placed at an intermediate point, observing a single direction of traffic and tracking the delay sample and the relative timestamp, can measure the round-trip delay of the connection.
中間点に配置されたオブザーバーは、トラフィックの単一方向を観察し、遅延サンプルと相対的なタイムスタンプを追跡することで、接続の往復遅延を測定できます。
The delay sample lifetime comprises two phases: initialization and reflection. The initialization is the generation of the delay sample, while the reflection realizes the bounce behavior of this single packet between the two endpoints.
遅延サンプルの寿命は、初期化と反射の2つのフェーズで構成されています。初期化は遅延サンプルの生成ですが、反射は2つのエンドポイント間のこの単一パケットのバウンス動作を実現します。
The next figure describes the elementary Delay bit mechanism.
次の図は、基本遅延ビットメカニズムについて説明しています。
+--------+ - - - - - +--------+
| | -----------> | |
| Client | | Server |
| | <----------- | |
+--------+ - - - - - +--------+
(a) No traffic at beginning.
+--------+ 0 0 1 - - +--------+
| | -----------> | |
| Client | | Server |
| | <----------- | |
+--------+ - - - - - +--------+
(b) The Client starts sending data and sets
the first packet as the delay sample.
+--------+ 0 0 0 0 0 +--------+
| | -----------> | |
| Client | | Server |
| | <----------- | |
+--------+ - - - 1 0 +--------+
(c) The Server starts sending data
and reflects the delay sample.
+--------+ 0 1 0 0 0 +--------+
| | -----------> | |
| Client | | Server |
| | <----------- | |
+--------+ 0 0 0 0 0 +--------+
(d) The Client reflects the delay sample.
+--------+ 0 0 0 0 0 +--------+
| | -----------> | |
| Client | | Server |
| | <----------- | |
+--------+ 0 0 0 1 0 +--------+
(e) The Server reflects the delay sample
and so on.
Figure 1: Delay Bit Mechanism
図1：遅延ビットメカニズム
Only the client is actively involved in the Generation Phase. It maintains an internal per-flow timestamp variable (ds_time) updated every time a delay sample is transmitted.
クライアントのみが生成フェーズに積極的に関与しています。遅延サンプルが送信されるたびに更新される内部フローごとのタイムスタンプ変数（DS_TIME）を維持します。
When connection starts, the client generates a new delay sample initializing the Delay bit of the first outgoing packet to 1. Then it updates the ds_time variable with the timestamp of its transmission.
接続が始まると、クライアントは、最初の発信パケットの初期化ビットを1に初期化する新しい遅延サンプルを生成し、その後、送信のタイムスタンプでDS_TIME変数を更新します。
The server initializes the Delay bit to 0 at the beginning of the connection, and its only task during the connection is described in Section 2.2.2.
サーバーは、接続の開始時に遅延ビットを0に初期化し、接続中のタスクのみをセクション2.2.2で説明します。
In absence of network impairments, the delay sample should bounce between the client and server continuously for the entire duration of the connection. However, that is highly unlikely for two reasons:
ネットワーク障害がない場合、遅延サンプルは、接続の期間中、クライアントとサーバーの間で継続的に跳ね返る必要があります。ただし、それは2つの理由で非常にありそうにありません。
1. The packet carrying the Delay bit might be lost.
1. 遅延ビットを運ぶパケットが失われる可能性があります。
2. An endpoint could stop or delay sending packets because the application is limiting the amount of traffic transmitted.
2. アプリケーションが送信されるトラフィックの量を制限しているため、エンドポイントはパケットの送信を停止または遅延させる可能性があります。
To deal with these problems, the client generates a new delay sample if more than a predetermined time (T_Max) has elapsed since the last delay sample transmission (including reflections). Note that T_Max should be greater than the max measurable RTT on the network. See Section 2.2.3 for details.
これらの問題に対処するために、事前に決められた時間（T_MAX）が最後の遅延サンプル伝送（反射を含む）以来経過している場合、クライアントは新しい遅延サンプルを生成します。T_MAXは、ネットワーク上の最大測定可能なRTTよりも大きくなければならないことに注意してください。詳細については、セクション2.2.3を参照してください。
Reflection is the process that enables the bouncing of the delay sample between a client and a server. The behavior of the two endpoints is almost the same.
反射とは、クライアントとサーバー間の遅延サンプルのバウンスを可能にするプロセスです。2つのエンドポイントの動作はほぼ同じです。
* Server-side reflection: When a delay sample arrives, the server marks the first packet in the opposite direction as the delay sample.
* サーバー側の反射：遅延サンプルが到着すると、サーバーは最初のパケットを遅延サンプルとして反対方向にマークします。
* Client-side reflection: When a delay sample arrives, the client marks the first packet in the opposite direction as the delay sample. It also updates the ds_time variable when the outgoing delay sample is actually forwarded.
* クライアント側の反射：遅延サンプルが到着すると、クライアントは最初のパケットを反対方向にマークし、遅延サンプルとマークします。また、発信遅延サンプルが実際に転送されたときにDS_TIME変数を更新します。
In both cases, if the outgoing delay sample is being transmitted with a delay greater than a predetermined threshold after the reception of the incoming delay sample (1 ms by default), the delay sample is not reflected, and the outgoing Delay bit is kept at 0.
どちらの場合も、発信遅延サンプルが、着信遅延サンプル（デフォルトでは1ミリ秒）の受信後、所定のしきい値を超える遅延で送信されている場合、遅延サンプルは反映されず、発信遅延ビットは0。
By doing so, the algorithm can reject measurements that would overestimate the delay due to lack of traffic at the endpoints. Hence, the maximum estimation error would amount to twice the threshold (e.g., 2 ms) per measurement.
そうすることで、アルゴリズムは、エンドポイントでのトラフィックの不足により遅延を過大評価する測定値を拒否できます。したがって、最大推定誤差は、測定あたりのしきい値の2倍（例：2 ms）になります。
The internal ds_time variable allows a client to identify delay sample losses. Considering that a lost delay sample is regenerated at the end of an explicit time (T_Max) since the last generation, this same value can be used by an observer to reject a measure and start a new one.
内部DS_TIME変数により、クライアントは遅延サンプル損失を識別できます。Lost Delayサンプルは、最後の世代以降の明示的な時間（T_MAX）の終わりに再生されることを考慮すると、この同じ値をオブザーバーが測定を拒否して新しいものを開始するために使用できます。
In other words, if the difference in time between two delay samples is greater or equal than T_Max, then these cannot be used to produce a delay measure. Therefore, the value of T_Max must also be known to the on-path network probes.
言い換えれば、2つの遅延サンプル間の時間の差がT_MAXよりも大きいまたは等しい場合、これらを使用して遅延測定を生成することはできません。したがって、T_MAXの値も、オンパスネットワークプローブにも知られている必要があります。
There are two alternatives to selecting the T_Max value so that both the client and observers know it. The first one requires that T_Max is known a priori (T_Max_p) and therefore set within the protocol specifications that implements the marking mechanism (e.g., 1 second, which usually is greater than the max expected RTT). The second alternative requires a dynamic mechanism able to adapt the duration of the T_Max to the delay of the connection (T_Max_c).
クライアントとオブザーバーの両方がそれを知るように、T_MAX値を選択することには2つの選択肢があります。最初のものは、T_MAXが先験的に既知であることが必要であり、したがって、マーキングメカニズムを実装するプロトコル仕様内に設定する必要があります（たとえば、1秒、通常は最大予想RTTよりも大きい）。2番目の代替案には、T_MAXの持続時間を接続の遅延（T_MAX_C）に適応できる動的メカニズムが必要です。
For instance, the client and observers could use the connection RTT as a basis for calculating an effective T_Max. They should use a predetermined initial value so that T_Max = T_Max_p (e.g., 1 second) and then, when a valid RTT is measured, change T_Max accordingly so that T_Max = T_Max_c. In any case, the selected T_Max should be large enough to absorb any possible variations in the connection delay. This also helps to prevent the mechanism from failing when the observer cannot recognize sudden changes in RTT exceeding T_Max.
たとえば、クライアントとオブザーバーは、効果的なT_MAXを計算するための基礎として接続RTTを使用できます。T_MAX = T_MAX_P（たとえば、1秒）にして、有効なRTTが測定されたら、T_MAX = T_MAX_Cを変更して、有効なRTTを測定すると、事前に決定された初期値を使用する必要があります。いずれにせよ、選択したT_MAXは、接続遅延の可能な変動を吸収するのに十分な大きさでなければなりません。これは、観察者がT_MAXを超えるRTTの突然の変化を認識できない場合、メカニズムが失敗するのを防ぐのにも役立ちます。
T_Max_c could be computed as two times the measured RTT plus a fixed amount of time (100 ms) to prevent low T_Max values in the case of very small RTTs. The resulting formula is: T_Max_c = 2RTT + 100 ms. If T_Max_c is greater than T_Max_p, then T_Max_c is forced to the T_Max_p value. Note that the value of 100 ms is provided as an example, and it may be chosen differently depending on the specific scenarios. For instance, an implementer may consider using existing protocol-specific values if appropriate.
T_MAX_Cは、測定されたRTTの2倍と固定時間（100ミリ秒）として計算して、非常に少ないRTTの場合に低いT_MAX値を防ぐことができます。結果の式は次のとおりです。T_MAX_C= 2RTT 100 ms。T_MAX_CがT_MAX_Pよりも大きい場合、T_MAX_CはT_MAX_P値に強制されます。100 msの値は例として提供されており、特定のシナリオに応じて異なる方法で選択される場合があることに注意してください。たとえば、実装者は、必要に応じて既存のプロトコル固有の値の使用を検討する場合があります。
Note that the observer's T_Max should always be less than or equal to the client's T_Max to avoid considering as a valid measurement what is actually the client's T_Max. To obtain this result, the client waits for two consecutive incoming samples and computes the two related RTTs. Then it takes the largest of them as the basis of the T_Max_c formula. At this point, observers have already measured a valid RTT and then computed their T_Max_c.
オブザーバーのT_MAXは、実際にクライアントのT_MAXである有効な測定として考慮しないように、常にクライアントのT_MAX以下である必要があることに注意してください。この結果を得るために、クライアントは2つの連続した着信サンプルを待ち、2つの関連するRTTを計算します。その後、それらの最大をT_MAX_Cフォーミュラの基礎として使用します。この時点で、オブザーバーはすでに有効なRTTを測定し、T_MAX_Cを計算しています。
When the Delay bit is used, a passive observer can use delay samples directly and avoid inherent ambiguities in the calculation of the RTT as can be seen in Spin bit analysis.
遅延ビットを使用すると、パッシブオブザーバーは遅延サンプルを直接使用し、スピンビット分析で見られるようにRTTの計算に固有の曖昧さを回避できます。
The delay sample generation process ensures that only one packet marked with the Delay bit set to 1 runs back and forth between two endpoints per round-trip time. To determine the RTT measurement of a flow, an on-path passive observer computes the time difference between two delay samples observed in a single direction.
遅延サンプル生成プロセスにより、1つの往復時間ごとに2つのエンドポイント間で1つの遅延ビットにマークされた1つのパケットのみが前後に実行されることが保証されます。フローのRTT測定を決定するために、パス中のパッシブオブザーバーは、単一の方向に観測された2つの遅延サンプル間の時差を計算します。
To ensure a valid measurement, the observer must verify that the distance in time between the two samples taken into account is less than T_Max.
有効な測定を確保するために、観察者は、考慮される2つのサンプル間の時間内の距離がT_MAXよりも少ないことを確認する必要があります。
=======================|======================>
= ********** -----Obs----> ********** =
= * Client * * Server * =
= ********** <------------ ********** =
<==============================================
(a) client-server RTT
==============================================>
= ********** ------------> ********** =
= * Client * * Server * =
= ********** <----Obs----- ********** =
<======================|=======================
(b) server-client RTT
Figure 2: Round-Trip Time (Both Directions)
図2：往復時間（両方の方向）
An observer that is able to observe both forward and return traffic directions can use the delay samples to measure "upstream" and "downstream" RTT components, also known as the half-RTT measurements. It does this by measuring the time between a delay sample observed in one direction and the delay sample previously observed in the opposite direction.
トラフィック方向と戻りの両方の方向を観察できるオブザーバーは、遅延サンプルを使用して、ハーフRTT測定とも呼ばれる「上流」と「下流」RTTコンポーネントを測定できます。これは、一方向に観察された遅延サンプルと、反対方向に以前に観察された遅延サンプルの間の時間を測定することにより行います。
As with RTT measurement, the observer must verify that the distance in time between the two samples taken into account is less than T_Max.
RTT測定と同様に、観察者は、考慮される2つのサンプル間の時間の距離がT_MAXよりも少ないことを確認する必要があります。
Note that upstream and downstream sections of paths between the endpoints and the observer (i.e., observer-to-client vs. client-to-observer and observer-to-server vs. server-to-observer) may have different delay characteristics due to the difference in network congestion and other factors.
エンドポイントとオブザーバーの間のパスの上流および下流のセクション（つまり、オブザーバーからクライアント対観測者、観測者とサーバーからサーバーへのサーバー対観測者）は、異なる遅延特性を持つ可能性があることに注意してください。ネットワークの混雑とその他の要因の違い。
=======================>
= ********** ------|-----> **********
= * Client * Obs * Server *
= ********** <-----|------ **********
<=======================
(a) client-observer half-RTT
=======================>
********** ------|-----> ********** =
* Client * Obs * Server * =
********** <-----|------ ********** =
<=======================
(b) observer-server half-RTT
Figure 3: Half Round-Trip Time (Both Directions)
図3：ハーフラウンドトリップ時間（両方の方向）
Intra-domain RTT is the portion of the entire RTT used by a flow to traverse the network of a provider. To measure intra-domain RTT, two observers capable of observing traffic in both directions must be employed simultaneously at the ingress and egress of the network to be measured. Intra-domain RTT is the difference between the two computed upstream (or downstream) RTT components.
ドメイン内RTTは、プロバイダーのネットワークを通過するためにフローによって使用されるRTT全体の部分です。ドメイン内RTTを測定するには、測定するネットワークの入り口と出口で、両方向のトラフィックを観察できる2人のオブザーバーを同時に使用する必要があります。ドメイン内RTTは、計算された2つの上流（または下流）RTTコンポーネントの違いです。
=========================================>
= =====================>
= = ********** ---|--> ---|--> **********
= = * Client * Obs Obs * Server *
= = ********** <--|--- <--|--- **********
= <=====================
<=========================================
(a) client-observer RTT components (half-RTTs)
==================>
********** ---|--> ---|--> **********
* Client * Obs Obs * Server *
********** <--|--- <--|--- **********
<==================
(b) the intra-domain RTT resulting from the
subtraction of the above RTT components
Figure 4: Intra-domain Round-Trip Time (Client-Observer: Upstream)
図4：ドメイン内の往復時間（クライアントオブザーバー：上流）
An on-path observer maintains an internal per-flow variable to keep track of the time at which the last delay sample has been observed. The flow characterization should be part of the protocol.
オンパスオブザーバーは、最後の遅延サンプルが観察された時間を追跡するために、内部あたりの変数を維持します。フローの特性評価は、プロトコルの一部である必要があります。
If the observer is unidirectional or in case of asymmetric routing, then upon detecting a delay sample:
オブザーバーが単方向である場合、または非対称ルーティングの場合は、遅延サンプルを検出したら：
* if a delay sample was also detected previously in the same direction and the distance in time between them is less than T_Max - K, then the two delay samples can be used to calculate RTT measurement. K is a protection threshold to absorb differences in T_Max computation and delay variations between two consecutive delay samples (e.g., K = 10% T_Max).
* 遅延サンプルが以前に同じ方向に検出され、それらの間の時間内の距離がT_max -k未満である場合、2つの遅延サンプルを使用してRTT測定を計算できます。Kは、2つの連続した遅延サンプル間のT_MAX計算と遅延の変動の違いを吸収するための保護しきい値です（例：K = 10％T_MAX）。
If the observer can observe both forward and return traffic flows, and it is able to determine which direction contains the client and the server (e.g., by observing the connection handshake), then upon detecting a delay sample:
オブザーバーがトラフィックフローと返品の両方を観察できる場合、およびクライアントとサーバーにどの方向が含まれるかを判断できる場合（たとえば、接続ハンドシェイクを観察することにより）、遅延サンプルを検出すると：
* if a delay sample was also detected in the opposite direction and the distance in time between them is less than T_Max - K, then the two delay samples can be used to measure the observer-client half-RTT or the observer-server half-RTT, according to the direction of the last delay sample observed.
* 遅延サンプルが反対方向に検出され、それらの間の時間内の距離がT_MAX-Kよりも少ない場合、2つの遅延サンプルを使用して、オブザーバークライアントハーフRTTまたはオブザーバーサーバーハーフ-RTTを測定できます、観察された最後の遅延サンプルの方向に従って。
Note that the accuracy can be influenced by what the observer is capable of observing. Additionally, the type of measurement differs, as described in the previous sections.
精度は、オブザーバーが観察できるものによって影響を受ける可能性があることに注意してください。さらに、前のセクションで説明されているように、測定のタイプは異なります。
The Spin and Delay bit algorithms work independently. If both marking methods are used in the same connection, observers can choose the best measurement between the two available:
スピンおよび遅延ビットアルゴリズムは独立して動作します。両方のマーキングメソッドが同じ接続で使用されている場合、オブザーバーは利用可能な2つの間で最適な測定値を選択できます。
* when a precise measurement can be produced using the Delay bit, observers choose it; and
* 遅延ビットを使用して正確な測定を生成できる場合、オブザーバーはそれを選択します。そして
* when a Delay bit measurement is not available, observers choose the approximate Spin bit one.
* 遅延ビット測定が利用できない場合、オブザーバーはおおよそのスピンビット1を選択します。
This section introduces bits that can be used for loss measurements. Whenever this section of the specification refers to packets, it is referring only to packets with protocol headers that include the loss bits -- the only packets whose loss can be measured.
このセクションでは、損失測定に使用できるビットを紹介します。仕様のこのセクションがパケットを指すたびに、損失ビットを含むプロトコルヘッダーを持つパケットのみを参照しています。これは、損失を測定できる唯一のパケットです。
T:
T：
The "round-Trip loss" bit is used in combination with the Spin bit to measure round-trip loss. See Section 3.1.
「往復損失」ビットは、スピンビットと組み合わせて使用され、往復損失を測定します。セクション3.1を参照してください。
Q:
Q：
The "sQuare" bit is used to measure upstream loss. See Section 3.2.
「平方」ビットは、上流の損失を測定するために使用されます。セクション3.2を参照してください。
L:
L：
The "Loss Event" bit is used to measure end-to-end loss. See Section 3.3.
「損失イベント」ビットは、エンドツーエンドの損失を測定するために使用されます。セクション3.3を参照してください。
R:
R：
The "Reflection square" bit is used in combination with the Q bit to measure end-to-end loss. See Section 3.4.
「反射四角」ビットは、Qビットと組み合わせて使用され、エンドツーエンドの損失を測定します。セクション3.4を参照してください。
Loss measurements enabled by T, Q, and L bits can be implemented by those loss bits alone (T bit requires a working Spin bit). Two-bit combinations Q+L and Q+R enable additional measurement opportunities discussed below.
T、Q、およびLビットによって有効な損失測定は、これらの損失ビットのみによって実装できます（Tビットには、動作するスピンビットが必要です）。2ビットの組み合わせq lとq rを使用して、以下で説明する追加の測定機会を可能にします。
Each endpoint maintains appropriate counters independently and separately for each identifiable flow (or each sub-flow for multipath connections).
各エンドポイントは、各識別可能なフロー（またはマルチパス接続用の各サブフロー）に対して、適切なカウンターを独立して個別に維持します。
Since loss is reported independently for each flow, all bits (except for the L bit) require a certain minimum number of packets to be exchanged per flow before any signal can be measured. Therefore, loss measurements work best for flows that transfer more than a minimal amount of data.
損失は各フローで独立して報告されるため、すべてのビット（Lビットを除く）では、信号を測定する前に、フローごとに特定の最小パケット数を交換する必要があります。したがって、損失測定は、最小限のデータを超えるデータを転送するフローに最適です。
The round-Trip loss bit is used to mark a variable number of packets exchanged twice between the endpoints realizing a two round-trip reflection. A passive on-path observer, observing either direction, can count and compare the number of marked packets seen during the two reflections, estimating the loss rate experienced by the connection. The overall exchange comprises:
往復損失ビットは、2つの往復反射を実現するエンドポイント間で2回交換される変数数のパケットをマークするために使用されます。いずれかの方向を観察するパッシブオンパスオブザーバーは、2つの反射中に見られるマークされたパケットの数をカウントして比較し、接続が経験する損失率を推定できます。全体的な交換は次のとおりです。
* the client selects and consequently sets the T bit to 1 in order to identify a first train of packets;
* クライアントは、最初のパケットトレインを識別するために、Tビットを1に選択し、その結果、1に設定します。
* upon receiving each packet included in the first train, the server sets the T bit to 1 and reflects to the client a respective second train of packets of the same size as the first train received;
* 最初の列車に含まれる各パケットを受信すると、サーバーはTビットを1に設定し、クライアントに最初の列車が受け取ったのと同じサイズのパケットのそれぞれのパケットを反映します。
* upon receiving each packet included in the second train, the client sets the T bit to 1 and reflects to the server a respective third train of packets of the same size as the second train received; and
* 2番目の列車に含まれる各パケットを受信すると、クライアントはTビットを1に設定し、2番目の列車が受け取ったのと同じサイズのそれぞれの3番目のパケットの列車をサーバーに反映します。そして
* upon receiving each packet included in the third train, the server sets the T bit to 1 and finally reflects to the client a respective fourth train of packets of the same size as the third train received.
* 3番目の列車に含まれる各パケットを受信すると、サーバーはTビットを1に設定し、最終的にクライアントに3番目の列車と同じサイズのパケットの4番目のパケットを反映します。
Packets belonging to the first round trip (first and second train) represent the Generation Phase, while those belonging to the second round trip (third and fourth train) represent the Reflection Phase.
1回目のラウンド旅行（1回目と2回目の列車）に属するパケットは、生成フェーズを表し、2回目のラウンド旅行（3回目と4回目の列車）に属するパケットは反射フェーズを表します。
A passive on-path observer can count and compare the number of marked packets seen during the two round trips (i.e., the first and third or the second and the fourth trains of packets, depending on which direction is observed) and estimate the loss rate experienced by the connection. This process is repeated continuously to obtain more measurements as long as the endpoints exchange traffic. These measurements can be called round-trip losses.
受動的なオンパスオブザーバーは、2回のラウンド旅行中に見られるマークされたパケットの数をカウントして比較できます（つまり、どの方向が観察されているかに応じて、パケットの1番目と3番目の列車と4番目の列車）を比較し、損失率を推定できます。接続の経験があります。このプロセスは、エンドポイントがトラフィックを交換する限り、より多くの測定値を取得するために継続的に繰り返されます。これらの測定値は、往復損失と呼ばれます。
Since the packet rates in two directions may be different, the number of marked packets in the train is determined by the direction with the lowest packet rate. See Section 3.1.2 for details on packet generation.
2つの方向のパケットレートは異なる場合があるため、列車内のマークされたパケットの数は、パケットレートが最も低い方向によって決まります。パケット生成の詳細については、セクション3.1.2を参照してください。
Since the measurements are performed on a portion of the traffic exchanged between the client and the server, the observer calculates the end-to-end Round-Trip Packet Loss (RTPL) that, statistically, will correspond to the loss rate experienced by the connection along the entire network path.
測定値はクライアントとサーバーの間で交換されるトラフィックの一部で実行されるため、オブザーバーはエンドツーエンドのラウンドトリップパケット損失（RTPL）を計算します。ネットワークパス全体に沿って。
=======================|======================>
= ********** -----Obs----> ********** =
= * Client * * Server * =
= ********** <------------ ********** =
<==============================================
(a) client-server RTPL
==============================================>
= ********** ------------> ********** =
= * Client * * Server * =
= ********** <----Obs----- ********** =
<======================|=======================
(b) server-client RTPL
Figure 5: Round-Trip Packet Loss (Both Directions)
図5：往復パケット損失（両方の方向）
This methodology also allows the half-RTPL measurement and the Intra-domain RTPL measurement in a way similar to RTT measurement.
この方法論により、RTT測定と同様の方法で、Half-RTPL測定とドメイン内RTPL測定も可能になります。
=======================>
= ********** ------|-----> **********
= * Client * Obs * Server *
= ********** <-----|------ **********
<=======================
(a) client-observer half-RTPL
=======================>
********** ------|-----> ********** =
* Client * Obs * Server * =
********** <-----|------ ********** =
<=======================
(b) observer-server half-RTPL
Figure 6: Half Round-Trip Packet Loss (Both Directions)
図6：ハーフラウンドトリップパケット損失（両方の方向）
=========================================>
=====================> =
********** ---|--> ---|--> ********** = =
* Client * Obs Obs * Server * = =
********** <--|--- <--|--- ********** = =
<===================== =
<=========================================
(a) observer-server RTPL components (half-RTPLs)
==================>
********** ---|--> ---|--> **********
* Client * Obs Obs * Server *
********** <--|--- <--|--- **********
<==================
(b) the intra-domain RTPL resulting from the
subtraction of the above RTPL components
Figure 7: Intra-domain Round-Trip Packet Loss (Observer-Server)
図7：ドメイン内の往復パケット損失（オブザーバーサーバー）
The round-Trip loss signal requires a working Spin bit signal to separate trains of marked packets (packets with T bit set to 1). A "pause" of at least one empty Spin bit period between each phase of the algorithm serves as such a separator for the on-path observer. The connection between T bit and Spin bit helps the observer correlate packet trains.
往復損失信号には、マークされたパケットの列車を分離するための作業スピンシグナルが必要です（Tビットが1に設定されたパケット）。アルゴリズムの各フェーズ間の少なくとも1つの空のスピンビット期間の「一時停止」は、パスオンオブザーバーのそのようなセパレーターとして機能します。Tビットとスピンビットの間の接続は、オブザーバーがパケットトレインを相関させるのに役立ちます。
The client maintains a "generation token" count that is set to zero at the beginning of the session and is incremented every time a packet is received (marked or unmarked). The client also maintains a "reflection counter" that starts at zero at the beginning of the session.
クライアントは、セッションの開始時にゼロに設定され、パケットを受信するたびに増加する（マークまたはマークなし）「ジェネレーショントークン」カウントを維持します。クライアントはまた、セッションの開始時にゼロから始まる「反射カウンター」を維持します。
The client is in charge of launching trains of marked packets and does so according to the algorithm:
クライアントは、マークされたパケットの列車の発射を担当しており、アルゴリズムに従って次のことを行います。
1. Generation Phase. The client starts generating marked packets for two consecutive Spin bit periods. When the client transmits a packet and a "generation token" is available, the client marks the packet and retires a "generation token". If no token is available, the outgoing packet is transmitted unmarked. At the end of the first Spin bit period spent in generation, the reflection counter is unlocked to start counting incoming marked packets that will be reflected later.
1. 生成フェーズ。クライアントは、2つの連続したスピンビット期間のマークされたパケットの生成を開始します。クライアントがパケットを送信し、「ジェネレーショントークン」が利用可能になると、クライアントはパケットをマークし、「ジェネレーショントークン」を廃止します。トークンがない場合、発信パケットはマークなしで送信されます。生成に費やされた最初のスピンビット期間の終わりに、リフレクションカウンターのロックが解除され、後で反射する入っているマークされたパケットのカウントを開始します。
2. Pause Phase. When the generation is completed, the client pauses till it has observed one entire Spin bit period with no marked packets. That Spin bit period is used by the observer as a separator between generated and reflected packets. During this marking pause, all the outgoing packets are transmitted with T bit set to 0. The reflection counter is still incremented every time a marked packet arrives.
2. 一時停止フェーズ。発電が完了すると、クライアントは、マークされたパケットなしで1つのスピンビット期間全体を観察するまで一時停止します。このスピンビット期間は、オブザーバーが生成されたパケットと反射パケットの間のセパレーターとして使用します。このマーキングの一時停止中、すべての発信パケットは、マークされたパケットが到着するたびに、0に設定されたTビット設定で送信されます。
3. Reflection Phase. The client starts transmitting marked packets, decrementing the reflection counter for each transmitted marked packet until the reflection counter has reached zero. The "generation token" method from the Generation Phase is used during this phase as well. At the end of the first Spin bit period spent in reflection, the reflection counter is locked to avoid incoming reflected packets incrementing it.
3. 反射フェーズ。クライアントは、マークされたパケットの送信を開始し、反射カウンターがゼロになるまで送信された各マークパケットの反射カウンターを減らします。生成フェーズの「生成トークン」メソッドは、このフェーズでも使用されます。反射に費やされた最初のスピンビット期間の終わりに、反射カウンターがロックされており、収縮する反射パケットがインクリメントされないようにします。
4. Pause Phase 2. The Pause Phase is repeated after the Reflection Phase and serves as a separator between the reflected packet train and a new packet train.
4. 一時停止フェーズ2。一時停止フェーズは、反射フェーズの後に繰り返され、反射パケット列車と新しいパケット列車の間のセパレーターとして機能します。
The generation token counter should be capped to limit the effects of a subsequent sudden reduction in the other endpoint's packet rate that could prevent that endpoint from reflecting collected packets. A cap value of 1 is recommended.
ジェネレーショントークンカウンターは、そのエンドポイントが収集されたパケットを反映できないようにする可能性のある他のエンドポイントのパケットレートのその後の突然の減少の影響を制限するためにキャップする必要があります。1のキャップ値をお勧めします。
A server maintains a "marking counter" that starts at zero and is incremented every time a marked packet arrives. When the server transmits a packet and the "marking counter" is positive, the server marks the packet and decrements the "marking counter". If the "marking counter" is zero, the outgoing packet is transmitted unmarked.
サーバーは、ゼロから始まり、マークされたパケットが到着するたびにインクリメントされる「マーキングカウンター」を維持します。サーバーがパケットを送信し、「マーキングカウンター」がプラスになると、サーバーはパケットをマークし、「マーキングカウンター」を減少させます。「マーキングカウンター」がゼロの場合、発信パケットはマークなしで送信されます。
Note that a choice of 2 RTT (two Spin bit periods) for the Generation Phase is a trade-off between the percentage of marked packets (i.e., the percentage of traffic monitored) and the measurement delay. Using this value, the algorithm produces a measurement approximately every 6 RTT (2 generations, ~2 reflections, 2 pauses), marking ~1/3 of packets exchanged in the slower direction (see Section 3.1.4). Choosing a Generation Phase of 1 RTT, we would produce measurements every 4 RTT, monitoring ~1/4 of packets in the slower direction.
生成フェーズの2つのRTT（2つのスピンビット期間）の選択は、マークされたパケットの割合（つまり、監視対象のトラフィックの割合）と測定遅延の間のトレードオフであることに注意してください。この値を使用して、アルゴリズムは約6 RTT（2世代、2つの反射、2ポーズ）ごとに測定値を生成し、より遅い方向に交換されるパケットの〜1/3をマークします（セクション3.1.4を参照）。1 RTTの生成フェーズを選択すると、4 RTTごとに測定値が作成され、パケットの〜1/4を遅い方向に監視します。
It is worth mentioning that problems can happen in some cases, especially if the rate suddenly changes, but the mechanism described here worked well with normal traffic conditions in the implementation.
特にレートが突然変化する場合、場合によっては問題が発生する可能性があることに言及する価値がありますが、ここで説明するメカニズムは、実装の通常の交通条件でうまく機能しました。
The on-path observer counts marked packets and separates different trains by detecting Spin bit periods (at least one) with no marked packets. The Round-Trip Packet Loss (RTPL) is the difference between the size of the Generation train and the Reflection train.
オンパスオブザーバーは、マークされたパケットをカウントし、マーク付きパケットなしでスピンビット期間（少なくとも1つ）を検出することにより、さまざまな列車を分離します。往復パケット損失（RTPL）は、世代列車のサイズと反射列車の違いです。
In the following example, packets are represented by two bits (first one is the Spin bit, second one is the round-Trip loss bit):
次の例では、パケットは2つのビットで表されます（最初はスピンビット、2つ目は往復損失ビットです）：
Generation Pause Reflection Pause
____________________ ______________ ____________________ ________
| | | | |
01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10
Figure 8: Round-Trip Loss Signal Example
図8：往復損失信号の例
Note that 5 marked packets have been generated, of which 4 have been reflected.
5つのマークされたパケットが生成され、そのうち4つが反映されていることに注意してください。
A cycle of the round-Trip loss signaling algorithm contains 2 RTTs of Generation phase, 2 RTTs of Reflection Phase, and 2 Pause Phases at least 1 RTT in duration each. Hence, the loss signal is delayed by about 6 RTTs since the loss events.
往復損失シグナル伝達アルゴリズムのサイクルには、2つの生成相、2つのRTTの反射フェーズ、およびそれぞれ少なくとも1つのRTT 2つの一時停止フェーズが含まれます。したがって、損失信号は、損失イベント以来、約6 RTTによって遅延されます。
The observer can only detect the loss of marked packets that occurs after its initial observation of the Generation Phase and before its subsequent observation of the Reflection Phase. Hence, if the loss occurs on the path that sends packets at a lower rate (typically ACKs in such asymmetric scenarios), 2/6 (1/3) of the packets will be sampled for loss detection.
オブザーバーは、生成フェーズの最初の観察の後に発生するマークされたパケットの損失と、その後の反射段階の観察の前にのみ検出できます。したがって、損失がパケットをより低いレートで送信するパス（通常、非対称シナリオのACK）で発生する場合、パケットの2/6（1/3）が損失検出のためにサンプリングされます。
If the loss occurs on the path that sends packets at a higher rate, lowPacketRate/(3*highPacketRate) of the packets will be sampled for loss detection. For protocols that use ACKs, the portion of packets sampled for loss in the higher rate direction during unidirectional data transfer is 1/(3*packetsPerAck), where the value of packetsPerAck can vary by protocol, by implementation, and by network conditions.
パケットをより高いレートで送信するパスで損失が発生した場合、パケットのローパケットタート/（3*ハイパケットタート）が損失検出のためにサンプリングされます。ACKSを使用するプロトコルの場合、単方向データ転送中に高いレート方向で損失のためにサンプリングされるパケットの部分は1/（3*packetsperack）であり、Packetsperackの値はプロトコル、実装、およびネットワーク条件によって異なります。
The sQuare bit (Q bit) takes its name from the square wave generated by its signal. This method is based on the Alternate-Marking method [AltMark], and the Q bit represents the "packet color" that can be switched between 0 and 1 in order to mark consecutive blocks of packets with different colors. This method does not require cooperation from both endpoints.
正方形ビット（Qビット）は、その信号によって生成された四角波からその名前を取得します。この方法は、代替マーキング方法[Altmark]に基づいており、Qビットは、異なる色のパケットブロックの連続したブロックをマークするために、0と1の間に切り替えることができる「パケット色」を表します。この方法では、両方のエンドポイントからの協力は必要ありません。
[AltMark] introduces two variations of the Alternate-Marking method depending on whether the color is switched according to a fixed timer or after a fixed number of packets. Cooperating and synchronized observers on either end of a network segment can use the fixed-timer method to measure packet loss on the segment by comparing packet counters for the same packet blocks. The time length of the blocks can be chosen depending on the desired measurement frequency, but it must be long enough to guarantee the proper operation with respect to clock errors and network delay issues.
[Altmark]は、色が固定タイマーに従って切り替えられているか、固定数のパケットの後に切り替えられているかに応じて、代替マルキング方法の2つのバリエーションを導入します。ネットワークセグメントの両端で協力して同期したオブザーバーは、固定タイマー法を使用して、同じパケットブロックのパケットカウンターを比較することにより、セグメントのパケット損失を測定できます。ブロックの時間の長さは、目的の測定周波数に応じて選択できますが、クロックエラーとネットワーク遅延の問題に関して適切な動作を保証するのに十分な長さでなければなりません。
The Q bit method described in this document chooses the color-switching method based on a fixed number of packets for each block. This approach has the advantage that it does not require cooperating or synchronized observers or network elements. Each probe can measure packet loss autonomously without relying on an external NMS. For the purpose of the packet loss measurement, all blocks have the same number of packets, and it is necessary to detect only the loss event and not to identify the exact block with losses.
このドキュメントで説明されているQビットメソッドは、各ブロックの固定数のパケットに基づいてカラースイッチングメソッドを選択します。このアプローチには、協力または同期したオブザーバーまたはネットワーク要素を必要としないという利点があります。各プローブは、外部NMSに依存することなく、自律的にパケット損失を測定できます。パケット損失測定の目的のために、すべてのブロックには同じ数のパケットがあり、損失イベントのみを検出し、損失のある正確なブロックを識別しないようにする必要があります。
Following the method based on fixed number of packets, the square wave signal is generated by the switching of the Q bit: every outgoing packet contains the Q bit value, which is initialized to 0 and inverted after sending N packets (a sQuare Block or simply Q Block). Hence, Q Period is 2*N.
固定数のパケット数に基づいてメソッドに従って、qビットの切り替えによって四角波信号が生成されます。すべての発信パケットにはqビット値が含まれています。Qブロック）。したがって、Q期間は2*nです。
Observation points can estimate upstream losses by watching a single direction of the traffic flow and counting the number of packets in each observed Q Block, as described in Section 3.2.2.
観測点は、セクション3.2.2で説明されているように、トラフィックフローの単一の方向を視聴し、観測された各Qブロックのパケットの数をカウントすることにより、上流の損失を推定できます。
The length of the block must be known to the on-path network probes. There are two alternatives to selecting the Q Block length. The first one requires that the length is known a priori and therefore set within the protocol specifications that implement the marking mechanism. The second requires the sender to select it.
ブロックの長さは、オンパスネットワークプローブに既知でなければなりません。Qブロック長を選択することには、2つの選択肢があります。1つ目は、長さが先験的に既知であるため、マーキングメカニズムを実装するプロトコル仕様内に設定されることを要求します。2番目には、送信者がそれを選択する必要があります。
In this latter scenario, the sender is expected to choose N (Q Block length) based on the expected amount of loss and reordering on the path. The choice of N strikes a compromise -- the observation could become too unreliable in case of packet reordering and/or severe loss if N is too small, while short flows may not yield a useful upstream loss measurement if N is too large (see Section 3.2.2).
この後者のシナリオでは、送信者は、パスでの予想される損失と並べ替えに基づいて、n（qブロック長）を選択すると予想されます。nの選択は妥協点を帯びます - nが小さすぎる場合、パケットの再注文や重度の損失の場合、観測は信頼性が高すぎる可能性がありますが、短いフローは、nが大きすぎる場合は有用な上流損失測定値をもたらさない可能性があります（セクションを参照3.2.2）。
The value of N should be at least 64 and be a power of 2. This requirement allows an observer to infer the Q Block length by observing one period of the square signal. It also allows the observer to identify flows that set the loss bits to arbitrary values (see Section 6).
nの値は少なくとも64で、2のパワーである必要があります。この要件により、観測者は正方形信号の1つの期間を観察することによりQブロック長を推測できます。また、オブザーバーは、損失ビットを任意の値に設定するフローを識別することができます（セクション6を参照）。
If the sender does not have sufficient information to make an informed decision about Q Block length, the sender should use N=64, since this value has been extensively tried in large-scale field tests and yielded good results. Alternatively, the sender may also choose a random power-of-2 N for each flow, increasing the chances of using a Q Block length that gives the best signal for some flows.
送信者がQブロック長について情報に基づいた決定を下すのに十分な情報を持っていない場合、この値は大規模なフィールドテストで広く試され、良い結果が得られたため、送信者はn = 64を使用する必要があります。あるいは、送信者は、各フローに対してランダムなパワー-2 nを選択し、一部のフローに最適な信号を提供するQブロック長を使用する可能性を高めることもできます。
The sender must keep the value of N constant for a given flow.
送信者は、特定のフローに対してnの値を一定に保つ必要があります。
Blocks of N (Q Block length) consecutive packets are sent with the same value of the Q bit, followed by another block of N packets with an inverted value of the Q bit. Hence, knowing the value of N, an on-path observer can estimate the amount of upstream loss after observing at least N packets. The upstream loss rate (uloss) is one minus the average number of packets in a block of packets with the same Q value (p) divided by N (uloss=1-avg(p)/N).
n（qブロック長）連続したパケットのブロックは、qビットの同じ値で送信され、その後、qビットの反転値を持つnパケットの別のブロックが続きます。したがって、Nの値を知っていると、パス上のオブザーバーは、少なくともNパケットを観察した後、上流の損失の量を推定できます。上流の損失率（ULOSS）は、同じQ値（P）をN（ULOSS = 1-AVG（P）/N）で割った同じQ値（P）を持つパケットブロック内のパケットの平均数を差し引いたものです。
The observer needs to be able to tolerate packet reordering that can blur the edges of the square signal, as explained in Section 3.2.3.
セクション3.2.3で説明されているように、オブザーバーは、正方形信号のエッジを曖昧にする可能性のあるパケットの並べ替えに耐えることができる必要があります。
=====================>
********** -----Obs----> **********
* Client * * Server *
********** <------------ **********
(a) in client-server channel (uloss_up)
********** ------------> **********
* Client * * Server *
********** <----Obs----- **********
<=====================
(b) in server-client channel (uloss_down)
Figure 9: Upstream Loss
図9：上流の損失
Packet reordering can produce spurious edges in the square signal. To address this, the observer should look for packets with the current Q bit value up to X packets past the first packet with a reverse Q bit value. The value of X, a "Marking Block Threshold", should be less than N/2.
パケットの並べ替えは、正方形信号にスプリアスなエッジを生成する可能性があります。これに対処するために、オブザーバーは、逆Qビット値を持つ最初のパケットを通過して、現在のQビット値をxパケットまでxパケットのパケットを探す必要があります。「マークブロックしきい値」であるxの値は、n/2未満でなければなりません。
The choice of X represents a trade-off between resiliency to reordering and resiliency to loss. A very large Marking Block Threshold will be able to reconstruct Q Blocks despite a significant amount of reordering, but it may erroneously coalesce packets from multiple Q Blocks into fewer Q Blocks if loss exceeds 50% for some Q Blocks.
Xの選択は、秩序化への回復力と損失への回復力との間のトレードオフを表しています。非常に大きなマーキングブロックのしきい値は、かなりの量の再注文にもかかわらずQブロックを再構築できますが、Qブロックの一部で損失が50％を超えると、複数のQブロックからQブロックの数が少ない場合に誤ってパケットを合体する可能性があります。
Burst losses can affect the accuracy of Q measurements. Generally, burst losses can be absorbed and correctly measured if smaller than the established Q Block length. If the entire Q Block length of packets is lost in a burst, however, the observer may be left completely unaware of the loss.
バースト損失は、Q測定の精度に影響を与える可能性があります。一般に、バースト損失は吸収され、確立されたQブロックの長さよりも小さい場合は正しく測定できます。ただし、パケットのQブロックの長さ全体がバーストで失われた場合、オブザーバーは損失に完全に気付かないままになる可能性があります。
To improve burst loss resilience, an observer may consider a received Q Block larger than the selected Q Block length as an indication of a burst loss event. The observer would then compute the loss as three times the Q Block length minus the measured block length. By doing so, the observer can detect burst losses of less than two blocks (e.g., less than 128 packets for a Q Block length of 64 packets). A burst loss of two or more consecutive periods would still remain unnoticed by the observer (or underestimated if a period longer than Q Block length were formed).
バースト損失の回復力を改善するために、オブザーバーは、選択されたQブロック長よりも大きい受信Qブロックをバースト損失イベントの表示と見なす場合があります。オブザーバーは、Qブロック長の3倍から測定ブロック長を引いたものとして損失を計算します。そうすることで、オブザーバーは2ブロック未満のバースト損失を検出できます（たとえば、64パケットのQブロック長の128パケット未満）。2つ以上の連続した期間のバースト損失は、オブザーバーによってまだ気付かれないままです（または、Qブロックの長さより長い期間が形成された場合、過小評価されます）。
The Loss Event bit uses an Unreported Loss counter maintained by the protocol that implements the marking mechanism. To use the Loss Event bit, the protocol must allow the sender to identify lost packets. This is true of protocols such as QUIC, partially true for TCP and Stream Control Transmission Protocol (SCTP) (losses of pure ACKs are not detected), and is not true of protocols such as UDP and IPv4/IPv6.
損失イベントビットは、マーキングメカニズムを実装するプロトコルによって維持される未報告の損失カウンターを使用します。損失イベントビットを使用するには、プロトコルで送信者が失われたパケットを識別できるようにする必要があります。これは、QUICなどのプロトコルに当てはまります。これは、TCPおよびストリーム制御伝送プロトコル（SCTP）（純粋なACKの損失は検出されません）に部分的に当てはまり、UDPやIPv4/IPv6などのプロトコルには当てはまりません。
The Unreported Loss counter is initialized to 0, and the L bit of every outgoing packet indicates whether the Unreported Loss counter is positive (L=1 if the counter is positive, and L=0 otherwise).
報告されていない損失カウンターは0に初期化され、すべての発信パケットのLビットは、報告されていない損失カウンターが正であるかどうかを示します（カウンターが正の場合はl = 1、l = 0それ以外の場合）。
The value of the Unreported Loss counter is decremented every time a packet with L=1 is sent.
報告されていない損失カウンターの値は、L = 1のパケットが送信されるたびに減少します。
The value of the Unreported Loss counter is incremented for every packet that the protocol declares lost, using whatever loss detection machinery the protocol employs. If the protocol is able to rescind the loss determination later, a positive Unreported Loss counter may be decremented due to the rescission. In general, it should not become negative due to the rescission, but it can happen in few cases.
報告されていない損失カウンターの値は、プロトコルが採用する損失検出機械を使用して、プロトコルが失われたパケットごとに増加します。プロトコルが後で損失の決定を取り消すことができる場合、撤回のために肯定的な非報告損失カウンターが減少する可能性があります。一般に、撤回のために否定的になるべきではありませんが、少数の場合に発生する可能性があります。
This loss signaling is similar to loss signaling in [ConEx], except that the Loss Event bit is reporting the exact number of lost packets, whereas the signal mechanism in [ConEx] is reporting an approximate number of lost bytes.
この損失シグナル伝達は、[Conex]の損失シグナル伝達に似ていますが、損失イベントビットが失われたパケットの正確な数を報告しているのに対し、[Conex]の信号メカニズムは、紛失したバイト数の約数を報告しています。
For protocols, such as TCP [TCP], that allow network devices to change data segmentation, it is possible that only a part of the packet is lost. In these cases, the sender must increment the Unreported Loss counter by the fraction of the packet data lost (so the Unreported Loss counter may become negative when a packet with L=1 is sent after a partial packet has been lost).
ネットワークデバイスがデータセグメンテーションを変更できるようにするTCP [TCP]などのプロトコルの場合、パケットの一部のみが失われる可能性があります。これらの場合、送信者はパケットデータの分数によって報告されていない損失カウンターを増やす必要があります（したがって、部分的なパケットが失われた後にL = 1のパケットが送信されると、報告されていない損失カウンターが負になる可能性があります）。
Observation points can estimate the end-to-end loss, as determined by the upstream endpoint, by counting packets in this direction with the L bit equal to 1, as described in Section 3.3.1.
観測点は、セクション3.3.1で説明されているように、この方向のパケットを1にカウントすることにより、上流のエンドポイントによって決定されるエンドツーエンドの損失を推定できます。
The Loss Event bit allows an observer to estimate the end-to-end loss rate by counting packets with L bit values of 0 and 1 for a given flow. The end-to-end loss ratio is the fraction of packets with L=1.
損失イベントビットにより、オブザーバーは、特定のフローに対してLビット値が0および1のパケットをカウントすることにより、エンドツーエンドの損失率を推定できます。エンドツーエンドの損失比は、L = 1のパケットの割合です。
The assumption here is that upstream loss affects packets with L=0 and L=1 equally. If some loss is caused by tail-drop in a network device, this may be a simplification. If the sender's congestion controller reduces the packet send rate after loss, there may be a sufficient delay before sending packets with L=1 that they have a greater chance of arriving at the observer.
ここでの仮定は、上流の損失がl = 0およびl = 1のパケットに等しく影響することです。ネットワークデバイスのテールドロップによって何らかの損失が引き起こされる場合、これは単純化される可能性があります。送信者の混雑コントローラーが損失後にパケット送信率を下げると、L = 1のパケットを送信する前に、観察者に到着する可能性が高くなる可能性があります。
The Loss Event bit allows an observer to characterize the loss profile, since the distribution of observed packets with the L bit set to 1 roughly corresponds to the distribution of packets lost between 1 RTT and 1 retransmission timeout (RTO) before (see Section 3.3.2.1). Hence, observing random single instances of the L bit set to 1 indicates random single packet loss, while observing blocks of packets with the L bit set to 1 indicates loss affecting entire blocks of packets.
損失イベントビットにより、オブザーバーは、1ビットを1に設定した観測されたパケットの分布が、1つのRTTから1つの再送信タイムアウト（RTO）の間で失われたパケットの分布にほぼ対応するため、損失プロファイルを特徴付けることができます（セクション3.3を参照してください。2.1）。したがって、lビットのランダムな単一インスタンスを1に観察することは、ランダムな単一パケット損失を示しますが、Lビット設定でパケットのブロックを観察すると、パケットのブロック全体に影響する損失が示されます。
Combining L and Q bits allows a passive observer watching a single direction of traffic to accurately measure:
LとQビットを組み合わせることで、パッシブオブザーバーが単一のトラフィック方向を視聴して正確に測定できます。
upstream loss:
上流の損失：
sender-to-observer loss (see Section 3.2.2)
送信者から観察者への損失（セクション3.2.2を参照）
downstream loss:
ダウンストリーム損失：
observer-to-receiver loss (see Section 3.3.2.2)
オブザーバーから受信者への損失（セクション3.3.2.2を参照）
end-to-end loss:
エンドツーエンドの損失：
sender-to-receiver loss on the observed path (see Section 3.3.1) with loss profile characterization (see Section 3.3.1.1)
観察されたパスでの送信者から受信者への損失（セクション3.3.1を参照）を備えたプロファイルの特性評価（セクション3.3.1.1を参照）
Upstream loss is calculated by observing packets that did not suffer the upstream loss (Section 3.2.2). End-to-end loss, however, is calculated by observing subsequent packets after the sender's protocol detected the loss. Hence, end-to-end loss is generally observed with a delay of between 1 RTT (loss declared due to multiple duplicate acknowledgments) and 1 RTO (loss declared due to a timeout) relative to the upstream loss.
上流の損失は、上流の損失に苦しんでいないパケットを観察することによって計算されます（セクション3.2.2）。ただし、エンドツーエンドの損失は、送信者のプロトコルが損失を検出した後に後続のパケットを観察することによって計算されます。したがって、上流の損失と比較して、1 RTT（複数の重複謝辞のために損失が宣言された損失）と1 RTO（タイムアウトのために宣言された損失）の間で、エンドツーエンドの損失が一般に観察されます。
The flow RTT can sometimes be estimated by timing the protocol handshake messages. This RTT estimate can be greatly improved by observing a dedicated protocol mechanism for conveying RTT information, such as the Spin bit (see Section 2.1) or Delay bit (see Section 2.2).
Flow RTTは、プロトコルハンドシェイクメッセージのタイミングによって推定される場合があります。このRTT推定値は、スピンビット（セクション2.1を参照）や遅延ビット（セクション2.2を参照）などのRTT情報を伝えるための専用プロトコルメカニズムを観察することで大幅に改善できます。
Whenever the observer needs to perform a computation that uses both upstream and end-to-end loss rate measurements, it should consider the upstream loss rate leading the end-to-end loss rate by approximately 1 RTT. If the observer is unable to estimate RTT of the flow, it should accumulate loss measurements over time periods of at least 4 times the typical RTT for the observed flows.
オブザーバーが上流とエンドツーエンドの損失率の両方の測定を使用する計算を実行する必要があるときはいつでも、エンドツーエンドの損失率を約1 RTTでリードする上流の損失率を考慮する必要があります。観察者がフローのRTTを推定できない場合、観測されたフローの典型的なRTTの少なくとも4倍の期間にわたって損失測定値を蓄積する必要があります。
If the calculated upstream loss rate exceeds the end-to-end loss rate calculated in Section 3.3.1, then either the Q Period is too short for the amount of packet reordering or there is observer loss, described in Section 3.3.2.3. If this happens, the observer should adjust the calculated upstream loss rate to match end-to-end loss rate, unless the following applies.
計算された上流の損失率がセクション3.3.1で計算されたエンドツーエンドの損失率を超える場合、Q期間はパケットの並べ替えの量に対して短すぎるか、セクション3.3.2.3で説明されているオブザーバー損失があります。これが発生した場合、オブザーバーは、次のものが適用されない限り、計算された上流の損失率をエンドツーエンドの損失率に合わせて調整する必要があります。
In case of a protocol, such as TCP or SCTP, that does not track losses of pure ACK packets, observing a direction of traffic dominated by pure ACK packets could result in measured upstream loss that is higher than measured end-to-end loss if said pure ACK packets are lost upstream. Hence, if the measurement is applied to such protocols, and the observer can confirm that pure ACK packets dominate the observed traffic direction, the observer should adjust the calculated end-to-end loss rate to match upstream loss rate.
TCPやSCTPなどのプロトコルの場合、それは純粋なACKパケットの損失を追跡せず、純粋なACKパケットが支配するトラフィックの方向を観察すると、測定されたエンドツーエンド損失よりも高い測定された上流損失をもたらす可能性があります。純粋なACKパケットは上流で失われると述べた。したがって、測定がそのようなプロトコルに適用され、オブザーバーが純粋なACKパケットが観測されたトラフィック方向を支配することを確認できる場合、観察者は計算されたエンドツーエンドの損失率を調整して上流の損失率に合わせる必要があります。
Because downstream loss affects only those packets that did not suffer upstream loss, the end-to-end loss rate (eloss) relates to the upstream loss rate (uloss) and downstream loss rate (dloss) as (1-uloss)(1-dloss)=1-eloss. Hence, dloss=(eloss-uloss)/(1-uloss).
ダウンストリーム損失は上流の損失に苦しんでいないパケットのみに影響するため、エンドツーエンドの損失率（ELOSS）は、上流の損失率（ULOSS）および下流損失率（DLOSS）として（1-oloss）（1-に関連しています。dloss）= 1-eloss。したがって、dloss =（eloss-uloss）/（1-uloss）。
A typical deployment of a passive observation system includes a network tap device that mirrors network packets of interest to a device that performs analysis and measurement on the mirrored packets. The observer loss is the loss that occurs on the mirror path.
受動的観測システムの典型的な展開には、ミラー化されたパケットで分析と測定を実行するデバイスの関心のあるネットワークパケットをミラーリングするネットワークタップデバイスが含まれます。オブザーバーの損失は、ミラーパスで発生する損失です。
Observer loss affects the upstream loss rate measurement since it causes the observer to account for fewer packets in a block of identical Q bit values (see Section 3.2.2). The end-to-end loss rate measurement, however, is unaffected by the observer loss since it is a measurement of the fraction of packets with the L bit value of 1, and the observer loss would affect all packets equally (see Section 3.3.1).
オブザーバーの損失は、上流の損失率の測定に影響を与えます。これにより、オブザーバーは同一のQビット値のブロックでのパケットが少なくなるためです（セクション3.2.2を参照）。ただし、エンドツーエンドの損失率の測定は、Lビット値が1のパケットの割合の測定であり、オブザーバーの損失がすべてのパケットに等しく影響するため、オブザーバーの損失の影響を受けません（セクション3.3を参照してください。1）。
The need to adjust the upstream loss rate down to match the end-to-end loss rate as described in Section 3.3.2.1 is an indication of the observer loss, whose magnitude is between the amount of such adjustment and the entirety of the upstream loss measured in Section 3.2.2. Alternatively, a high apparent upstream loss rate could be an indication of significant packet reordering, possibly due to packets belonging to a single flow being multiplexed over several upstream paths with different latency characteristics.
セクション3.3.2.1で説明されているエンドツーエンドの損失率に合わせて上流の損失率を調整する必要性は、そのような調整量と上流の損失の全体の間にあるオブザーバー損失の兆候です。セクション3.2.2で測定。あるいは、異なるレイテンシ特性を持ついくつかの上流パスで多重化されている単一のフローに属するパケットによると、見かけの高い上流の損失率は、おそらく単一のフローに属するパケットに属するパケットの並べ替えの兆候である可能性があります。
R bit requires a deployment alongside Q bit. Unlike the square signal for which packets are transmitted in blocks of fixed size, the number of packets in Reflection square blocks (also an Alternate-Marking signal) varies according to these rules:
rビットには、qビットと一緒に展開が必要です。パケットが固定サイズのブロックで送信される正方形信号とは異なり、これらのルールに従って、反射四角ブロックのパケットの数（代替マーク信号）は異なります。
* when the transmission of a new block starts, its size is set equal to the size of the last Q Block whose reception has been completed; and
* 新しいブロックの送信が始まると、そのサイズは、受信が完了した最後のQブロックのサイズに等しく設定されます。そして
* if the reception of at least one further Q Block is completed before transmission of the block is terminated, the size of the block is updated to be the average size of the further received Q Blocks.
* ブロックの送信が終了する前に少なくとも1つのQブロックの受信が完了すると、ブロックのサイズが更新され、さらに受信されたQブロックの平均サイズになります。
The Reflection square value is initialized to 0 and is applied to the R bit of every outgoing packet. The Reflection square value is toggled for the first time when the completion of a Q Block is detected in the incoming square signal (produced by the other endpoint using the Q bit). The number of packets detected within this first Q Block (p), is used to generate a reflection square signal that toggles every M=p packets (at first). This new signal produces blocks of M packets (marked using the R bit) and each of them is called "Reflection Block" (Reflection Block).
反射平方値は0に初期化され、すべての発信パケットのRビットに適用されます。反射四角値は、Qブロックの完了が着信四角信号（Qビットを使用して他のエンドポイントによって生成される）で初めて検出されたときに切り替えられます。この最初のQブロック（P）内で検出されたパケットの数は、すべてのM = Pパケットを切り替える反射四角信号を生成するために使用されます（最初）。この新しい信号は、Mパケットのブロック（Rビットを使用してマーク）を生成し、それぞれが「反射ブロック」（反射ブロック）と呼ばれます。
The M value is then updated every time a completed Q Block in the incoming square signal is received, following this formula: M=round(avg(p)).
次に、この式に従って、M = round（AVG（P））に従って、入力された四角信号の完了したQブロックを受信するたびにM値が更新されます。
The parameter avg(p), the average number of packets in a marking period, is computed based on all the Q Blocks received since the beginning of the current Reflection Block.
マーク期間の平均パケット数であるパラメーターAVG（P）は、現在の反射ブロックの開始以降に受信したすべてのQブロックに基づいて計算されます。
The transmission of a Reflection Block is considered complete (and the signal toggled) when the number of packets transmitted in that block is at least the latest computed M value.
反射ブロックの送信は、そのブロックに送信されるパケットの数が少なくとも最新の計算されたM値である場合、完全（および信号が切り替えられた）と見なされます。
To ensure a proper computation of the M value, endpoints implementing the R bit must identify the boundaries of incoming Q Blocks. The same approach described in Section 3.2.3 should be used.
M値を適切に計算するために、Rビットを実装するエンドポイントは、着信Qブロックの境界を識別する必要があります。セクション3.2.3で説明した同じアプローチを使用する必要があります。
By looking at the R bit, unidirectional observation points have an indication of loss experienced by the entire unobserved channel plus the loss on the path from the sender to them.
Rビットを見ると、一方向の観測点は、観察されていないチャネル全体と送信者から彼らへの経路の損失を経験した損失を示しています。
Since the Q Block is sent in one direction, and the corresponding reflected R Block is sent in the opposite direction, the reflected R signal is transmitted with the packet rate of the slowest direction. Namely, if the observed direction is the slowest, there can be multiple Q Blocks transmitted in the unobserved direction before a complete Reflection Block is transmitted in the observed direction. If the unobserved direction is the slowest, the observed direction can be sending R Blocks of the same size repeatedly before it can update the signal to account for a newly completed Q Block.
Qブロックは一方向に送信され、対応する反射Rブロックが反対方向に送信されるため、反射R信号は最も遅い方向のパケットレートで送信されます。つまり、観察された方向が最も遅い場合、完全な反射ブロックが観測された方向に送信される前に、観察されていない方向に複数のQブロックが送信される可能性があります。観測されていない方向が最も遅い場合、観測された方向は、新しく完成したQブロックを考慮して信号を更新する前に、同じサイズのRブロックを繰り返し送信することができます。
The use of the rounding function used in the M computation introduces errors that can be minimized by storing the rounding applied each time M is computed and using it during the computation of the M value in the following Reflection Block.
M計算で使用される丸め関数を使用すると、Mが計算されるたびに適用される丸めを保存することで最小限に抑えることができるエラーが導入され、次の反射ブロックのM値の計算中にそれを使用します。
This can be achieved by introducing the new r_avg parameter in the computation of M. The new formula is Mr=avg(p)+r_avg; M=round(Mr); r_avg=Mr-M where the initial value of r_avg is equal to 0.
これは、Mの計算に新しいR_AVGパラメーターを導入することで実現できます。新しい式はMR = AVG（P）R_AVGです。m = round（mr）;R_AVG = MR-Mここで、R_AVGの初期値は0に等しくなります。
When a protocol implementing the marking mechanism is able to detect when packets are received out of order, it can improve resilience to packet reordering beyond what is possible by using methods described in Section 3.2.3.
マーキングメカニズムを実装するプロトコルが、パケットが順番に受信されたときに検出できる場合、セクション3.2.3で説明した方法を使用して、可能なものを超えてパケットの並べ替えの回復力を向上させることができます。
This can be achieved by updating the size of the current Reflection Block while it is being transmitted. The Reflection Block size is then updated every time an incoming reordered packet of the previous Q Block is detected. This can be done if and only if the transmission of the current Reflection Block is in progress and no packets of the following Q Block have been received.
これは、送信中に現在の反射ブロックのサイズを更新することで実現できます。その後、前のQブロックの着信再注文パケットが検出されるたびに、反射ブロックサイズが更新されます。これは、現在の反射ブロックの送信が進行中で、次のQブロックのパケットが受信されていない場合にのみ実行できます。
Burst losses can affect the accuracy of R measurements similar to how they affect accuracy of Q measurements. Therefore, recommendations in Section 3.2.3.1 apply equally to improving burst loss resilience for R measurements.
バースト損失は、Q測定の精度にどのように影響するかと同様のR測定の精度に影響を与える可能性があります。したがって、セクション3.2.3.1の推奨事項は、R測定のバースト損失の回復力を改善することに等しく適用されます。
Since both sQuare and Reflection square bits are toggled at most every N packets (except for the first transition of the R bit as explained before), an on-path observer can count the number of packets of each marking block and, knowing the value of N, can estimate the amount of loss experienced by the connection. An observer can calculate different measurements depending on whether it is able to observe a single direction of the traffic or both directions.
正方形と反射の両方の正方形ビットは、すべてのNパケットで切り替えられているため（以前に説明したようにRビットの最初の遷移を除く）、パス上のオブザーバーは各マーキングブロックのパケットの数をカウントし、の値を知ることができます。n、接続が経験する損失の量を推定できます。オブザーバーは、トラフィックの単一方向を観察できるか、両方向を観察できるかに応じて、異なる測定値を計算できます。
Single directional observer:
単一の方向オブザーバー：
upstream loss in the observed direction:
観察された方向の上流の損失：
the loss between the sender and the observation point (see Section 3.2.2)
送信者と観測点の間の損失（セクション3.2.2を参照）
"three-quarters" connection loss:
「4分の3」接続損失：
the loss between the receiver and the sender in the unobserved direction plus the loss between the sender and the observation point in the observed direction
観察されていない方向にある受信者と送信者の間の損失に加えて、発見者と観測された方向の観測点との間の損失
end-to-end loss in the unobserved direction:
観察されていない方向におけるエンドツーエンドの損失：
the loss between the receiver and the sender in the opposite direction
反対方向にレシーバーと送信者の間の損失
upstream loss in the observed direction: the loss between the sender and the observation point (see Section 3.2.2) "three-quarters" connection loss: the loss between the receiver and the sender in the unobserved direction plus the loss between the sender and the observation point in the observed direction end-to-end loss in the unobserved direction: the loss between the receiver and the sender in the opposite direction
観察された方向の上流の損失：送信者と観察点の間の損失（セクション3.2.2を参照）「4分の3」接続損失：観察されていない方向における受信者と送信者の間の損失と、送信者と送信者との間の損失観察された方向の観測点が観察されていない方向のエンドツーエンドの損失：反対方向の受信機と送信者の間の損失
Two directions observer (same metrics seen previously applied to both direction, plus):
2つの方向オブザーバー（以前に見られたのと同じメトリックが両方方向に適用され、プラスに加えて）：
client-observer half round-trip loss:
クライアント - 観察者半分の往復損失：
the loss between the client and the observation point in both directions
クライアントと両方向の観測点の間の損失
observer-server half round-trip loss:
オブザーバーサーバーハーフラウンドトリップ損失：
the loss between the observation point and the server in both directions
両方向の観測点とサーバーの間の損失
downstream loss:
ダウンストリーム損失：
the loss between the observation point and the receiver (applicable to both directions)
観測点と受信機の間の損失（両方方向に適用）
client-observer half round-trip loss: the loss between the client and the observation point in both directions observer-server half round-trip loss: the loss between the observation point and the server in both directions downstream loss: the loss between the observation point and the receiver (applicable to both directions)
クライアント - 観察者半分の往復損失：クライアントと両方向の観測点との間の損失オブザーバーサーバーハーフラウンドトリップ損失：観測点と両方向のサーバー間の損失下流損失：観測間の損失ポイントとレシーバー（両方の方向に適用）
Except for the very first block in which there is nothing to reflect (a complete Q Block has not been yet received), packets are continuously R-bit marked into alternate blocks of size lower or equal than N. By knowing the value of N, an on-path observer can estimate the amount of loss that has occurred in the whole opposite channel plus the loss from the sender up to it in the observation channel. As for the previous metric, the three-quarters connection loss rate (tqloss) is one minus the average number of packets in a block of packets with the same R value (t) divided by N (tqloss=1-avg(t)/N).
反映するものがない最初のブロック（完全なQブロックはまだ受信されていません）を除き、パケットはNの値を知ることにより、Nよりも低いまたは等しいサイズまたは等しいサイズのブロックに連続的にマークされています。オンパスオブザーバーは、反対のチャネル全体で発生した損失の量と、観測チャネルの送信者からの損失を推定できます。以前のメトリックに関しては、4分の3の接続損失率（TQLOSS）は、同じR値（T）をN（TQLOSS = 1-AVG（T）/で割る同じR値（T）を持つパケットのブロック内の平均パケット数を引いたものです。n）。
=======================>
= ********** -----Obs----> **********
= * Client * * Server *
= ********** <------------ **********
<============================================
(a) in client-server channel (tqloss_up)
============================================>
********** ------------> ********** =
* Client * * Server * =
********** <----Obs----- ********** =
<=======================
(b) in server-client channel (tqloss_down)
Figure 10: Three-Quarters Connection Loss
図10：4分の3の接続損失
The following metrics derive from this last metric and the upstream loss produced by the Q bit.
次のメトリックは、この最後のメトリックとQビットによって生成される上流の損失に由来します。
End-to-end loss in the unobserved direction (eloss_unobserved) relates to the "three-quarters" connection loss (tqloss) and upstream loss in the observed direction (uloss) as (1-eloss_unobserved)(1-uloss)=1-tqloss. Hence, eloss_unobserved=(tqloss-uloss)/(1-uloss).
観察されていない方向（Eloss_unobsived）でのエンドツーエンドの損失は、「4分の3」接続損失（TQLOSS）と、観測された方向（ULOSS）での上流の損失に関連しています。tqloss。したがって、eloss_unobserved =（tqloss-uloss）/（1-uloss）。
********** -----Obs----> **********
* Client * * Server *
********** <------------ **********
<==========================================
(a) in client-server channel (eloss_down)
==========================================>
********** ------------> **********
* Client * * Server *
********** <----Obs----- **********
(b) in server-client channel (eloss_up)
Figure 11: End-To-End Loss in the Opposite Direction
図11：反対方向のエンドツーエンドの損失
If the observer is able to observe both directions of traffic, it is able to calculate two "half round-trip" loss measurements -- loss from the observer to the receiver (in a given direction) and then back to the observer in the opposite direction. For both directions, "half round-trip" loss (hrtloss) relates to "three-quarters" connection loss (tqloss_opposite) measured in the opposite direction and the upstream loss (uloss) measured in the given direction as (1-uloss)(1-hrtloss)=1-tqloss_opposite. Hence, hrtloss=(tqloss_opposite-uloss)/(1-uloss).
オブザーバーがトラフィックの両方の方向を観察できる場合、2つの「ハーフラウンドトリップ」損失測定を計算できます - オブザーバーからレシーバーへの損失（特定の方向）、そして反対側のオブザーバーに戻る方向。両方の方向について、「ハーフラウンドトリップ」損失（HRTLOSS）は、反対方向に測定された「3分の3」接続損失（TQLOSS_OPPOSITE）に関連し、与えられた方向として測定されたアップストリーム損失（ULOSS）に関連しています（1分散）（1-hrtloss）= 1-tqloss_opposite。したがって、hrtloss =（tqloss_opposite-uloss）/（1-uloss）。
=======================>
= ********** ------|-----> **********
= * Client * Obs * Server *
= ********** <-----|------ **********
<=======================
(a) client-observer half round-trip loss (hrtloss_co)
=======================>
********** ------|-----> ********** =
* Client * Obs * Server * =
********** <-----|------ ********** =
<=======================
(b) observer-server half round-trip loss (hrtloss_os)
Figure 12: Half Round-Trip Loss (Both Directions)
図12：半往復損失（両方の方向）
If the observer is able to observe both directions of traffic, it is able to calculate two downstream loss measurements using either end-to-end loss and upstream loss, similar to the calculation in Section 3.3.2.2, or "half round-trip" loss and upstream loss in the opposite direction.
オブザーバーがトラフィックの両方向を観察できる場合、セクション3.3.2.2または「ハーフラウンドトリップ」の計算と同様に、エンドツーエンド損失と上流損失のいずれかを使用して、2つのダウンストリーム損失測定値を計算できます。反対方向の損失と上流の損失。
For the latter, dloss=(hrtloss-uloss_opposite)/(1-uloss_opposite).
後者の場合、dloss =（hrtloss-uloss_opposite）/（1-uloss_opposite）。
=====================>
********** ------|-----> **********
* Client * Obs * Server *
********** <-----|------ **********
(a) in client-server channel (dloss_up)
********** ------|-----> **********
* Client * Obs * Server *
********** <-----|------ **********
<=====================
(b) in server-client channel (dloss_down)
Figure 13: Downstream Loss
図13：下流の損失
While the primary focus of this document is on exposing packet loss and delay, modern networks can report congestion before they are forced to drop packets, as described in [ECN]. When transport protocols keep ECN-Echo feedback under encryption, this signal cannot be observed by the network operators. When tasked with diagnosing network performance problems, knowledge of a congestion downstream of an observation point can be instrumental.
このドキュメントの主な焦点はパケットの損失と遅延の公開にありますが、最新のネットワークは、[ECN]で説明されているように、パケットをドロップすることを余儀なくされる前に混雑を報告できます。輸送プロトコルが暗号化下でECNエコーフィードバックを維持している場合、この信号はネットワーク演算子によって観察できません。ネットワークのパフォーマンスの問題の診断を担当する場合、観測点の下流の輻輳の知識は役立つ可能性があります。
If downstream congestion information is desired, this information can be signaled with an additional bit.
下流の混雑情報が必要な場合、この情報は追加のビットで通知できます。
E:
E：
The "ECN-Echo Event" bit is set to 0 or 1 according to the Unreported ECN-Echo counter, as explained below in Section 3.5.1.
セクション3.5.1で説明するように、「ECNエコーイベント」ビットは、報告されていないECNエコーカウンターに従って0または1に設定されます。
The Unreported ECN-Echo counter operates identically to Unreported Loss counter (Section 3.3), except it counts packets delivered by the network with Congestion Experienced (CE) markings, according to the ECN-Echo feedback from the receiver.
報告されていないECNエコーカウンターは、レシーバーからのECNエコーフィードバックによると、ネットワークが経験した（CE）マークを使用してネットワークによって配信されたパケットをカウントすることを除いて、報告されていない損失カウンターと同じように動作します。
This ECN-Echo signaling is similar to ECN signaling in [ConEx]. The ECN-Echo mechanism in QUIC provides the number of packets received with CE marks. For protocols like TCP, the method described in [ConEx-TCP] can be employed. As stated in [ConEx-TCP], such feedback can be further improved using a method described in [ACCURATE-ECN].
このECNエコーシグナル伝達は、[Conex]のECNシグナル伝達に似ています。QUICのECNエコーメカニズムは、CEマークで受信したパケットの数を提供します。TCPなどのプロトコルの場合、[conex-tcp]で説明されている方法を使用できます。[Conex-TCP]に記載されているように、[正確なECN]で説明されている方法を使用して、このようなフィードバックをさらに改善できます。
A network observer can count packets with the CE codepoint and determine the upstream CE-marking rate directly.
ネットワークオブザーバーは、CE CodePointでパケットをカウントし、上流のCEマークレートを直接決定できます。
Observation points can also estimate ECN-reported end-to-end congestion by counting packets in this direction with an E bit equal to 1.
観察点は、この方向にパケットをカウントすることにより、Eが1に等しいEをカウントすることにより、ECNから報告されたエンドツーエンドの混雑を推定することもできます。
The upstream CE-marking rate and end-to-end ECN-reported congestion can provide information about the downstream CE-marking rate. The presence of E bits along with L bits, however, can somewhat confound precise estimates of upstream and downstream CE markings if the flow contains packets that are not ECN capable.
上流のCEマーク率とエンドツーエンドのECN報告輻輳は、下流のCEマーク率に関する情報を提供できます。ただし、LビットとともにEビットの存在は、フローに能力がないパケットが含まれている場合、上流および下流のCEマークの正確な推定値をある程度混乱させることができます。
Some protocols, such as QUIC, support separate ECN-Echo counters. For example, Section 13.4.1 of [QUIC-TRANSPORT] describes separate counters for ECT(0), ECT(1), and ECN-CE. To better support such protocols, multiple E bits can be used, one per a corresponding ECN-Echo counter.
QUICなどの一部のプロトコルは、個別のECNエコーカウンターをサポートしています。たとえば、[Quic-Transport]のセクション13.4.1では、ECT（0）、ECT（1）、およびECN-CEの個別のカウンターについて説明します。このようなプロトコルをより適切にサポートするために、対応するECNエコーカウンターごとに複数のEビットを使用できます。
This section summarizes the marking methods described in this document, which proposes a toolkit of techniques that can be used separately, partly, or all together depending on the need.
このセクションでは、このドキュメントに記載されているマーキング方法をまとめたもので、必要に応じて個別に、部分的、またはすべて一緒に使用できる手法のツールキットを提案します。
For the delay measurement, it is possible to use the Spin bit and/or the Delay bit. A unidirectional or bidirectional observer can be used.
遅延測定の場合、スピンビットおよび/または遅延ビットを使用することができます。単方向または双方向のオブザーバーを使用できます。
+===============+======+=====================+=============+========+
| Method | # of | Available Delay | Impairments | # of |
| | bits | Metrics | Resiliency | meas. |
| | +==========+==========+ | |
| | | UniDir | BiDir | | |
| | | Observer | Observer | | |
+===============+======+==========+==========+=============+========+
| S: Spin Bit | 1 | RTT | x2, Half | low | very |
| | | | RTT | | high |
+---------------+------+----------+----------+-------------+--------+
| D: Delay | 1 | RTT | x2, Half | high | medium |
| Bit | | | RTT | | |
+---------------+------+----------+----------+-------------+--------+
| SD: Spin | 2 | RTT | x2, Half | high | very |
| Bit & Delay | | | RTT | | high |
| Bit * | | | | | |
+---------------+------+----------+----------+-------------+--------+
Table 1: Delay Comparison
表1：遅延比較
x2
x2
Same metric for both directions
両方方向に同じメトリック
*
*
Both bits work independently; an observer could use less accurate Spin bit measurements when Delay bit ones are unavailable.
両方のビットは独立して動作します。オブザーバーは、遅延ビットの測定が利用できない場合、より正確なスピンビット測定を使用できます。
For the Loss measurement, each row in Table 2 represents a loss-marking method. For each method, the table specifies the number of bits required in the header, the available metrics using a unidirectional or bidirectional observer, applicable protocols, measurement fidelity, and delay.
損失測定の場合、表2の各行は損失マルキング方法を表します。各方法について、テーブルは、ヘッダーに必要なビット数、単方向または双方向の観測者、適用可能なプロトコル、測定忠実度、および遅延を使用した利用可能なメトリックを指定します。
+============+====+==========================+====+=================+
| Method |Bits| Available Loss Metrics |Prto| Measurement |
| | | | | Aspects |
| | +============+=============+ +==========+======+
| | | UniDir | BiDir | | Fidelity |Delay |
| | | Observer | Observer | | | |
+============+====+============+=============+====+==========+======+
| T: Round- | $1 | RT | x2, Half RT | * |Rate by |~6 RTT|
| Trip Loss | | | | |sampling | |
| Bit | | | | |1/3 to | |
| | | | | |1/(3*ppa) | |
| | | | | |of pkts | |
| | | | | |over 2 | |
| | | | | |RTT | |
+------------+----+------------+-------------+----+----------+------+
| Q: sQuare | 1 | Upstream | x2 | * |Rate over |N pkts|
| Bit | | | | |N pkts |(e.g.,|
| | | | | |(e.g., |64) |
| | | | | |64) | |
+------------+----+------------+-------------+----+----------+------+
| L: Loss | 1 | E2E | x2 | # |Loss |Min: |
| Event Bit | | | | |shape |RTT, |
| | | | | |(and |Max: |
| | | | | |rate) |RTO |
+------------+----+------------+-------------+----+----------+------+
| QL: sQuare | 2 | Upstream | x2 | # |see Q |see Q |
| + Loss Ev. | +------------+-------------+----+----------+------+
| Bits | | Downstream | x2 | # |see Q|L |see L |
| | +------------+-------------+----+----------+------+
| | | E2E | x2 | # |see L |see L |
+------------+----+------------+-------------+----+----------+------+
| QR: sQuare | 2 | Upstream | x2 | * |Rate over |see Q |
| + Ref. Sq. | +------------+-------------+----+N*ppa +------+
| Bits | | 3/4 RT | x2 | * |pkts (see |N*ppa |
| | +------------+-------------+----+Q bit for |pkts |
| | | !E2E | E2E, | * |N) |(see Q|
| | | | Downstream, | | |bit |
| | | | Half RT | | |for N)|
+------------+----+------------+-------------+----+----------+------+
Table 2: Loss Comparison
表2：損失比較
*
*
All protocols
すべてのプロトコル
#
＃
Protocols employing loss detection (with or without pure ACK loss detection)
損失検出を採用するプロトコル（純粋なACK損失検出の有無にかかわらず）
$
$
Require a working Spin bit
作業スピンビットが必要です
!
！
Metric relative to the opposite channel
反対のチャネルに対するメトリック
x2
x2
Same metric for both directions
両方方向に同じメトリック
ppa
PPA
Packets-Per-Ack
パケット-PACK
Q|L
Q | l
See Q if Upstream loss is significant; L otherwise
上流の損失が重要な場合はQを参照してください。それ以外の場合は
E2E
E2E
End to end
端から端まで
By combining the information of the two tables above, it can be deduced that the solutions with 3 bits (i.e., QL or QR + S or D) or 4 bits (i.e., QL or QR + SD) allow having more complete and resilient measurements.
上記の2つのテーブルの情報を組み合わせることにより、3ビット（QLまたはQR SまたはD）または4ビット（QLまたはQR SD）を持つソリューションにより、より完全で回復力のある測定値を持つことができると推測できます。
The methodologies described in the previous sections are transport agnostic and can be applied in various situations. The choice of the methods also depends on the specific protocol. For example, QL is a good combination; however, if a protocol does not support, or cannot set, the L bit, QR is the only viable solution.
前のセクションで説明した方法論は、輸送不可知論者であり、さまざまな状況で適用できます。メソッドの選択は、特定のプロトコルにも依存します。たとえば、QLは良い組み合わせです。ただし、プロトコルがL BITをサポートしていない、または設定できない場合、QRは唯一の実行可能なソリューションです。
This document describes several measurement methods, but it is not expected that all methods will be implemented together. For example, only some of the methods described in this document (i.e., sQuare bit and Spin bit) are utilized in [CORE-COAP-PM]. Also, the binding of a delay signal to QUIC is partially described in Section 17.4 of [QUIC-TRANSPORT], which adds only the Spin bit to the first byte of the short packet header, leaving two reserved bits for future use (see Section 17.2.2 of [QUIC-TRANSPORT]).
このドキュメントでは、いくつかの測定方法について説明しますが、すべての方法が一緒に実装されることは予想されていません。たとえば、このドキュメントで説明されているメソッドの一部（つまり、正方形ビットとスピンビット）のみが[Core-Coap-PM]で使用されます。また、QUICへの遅延信号の結合は、[QUIC-Transport]のセクション17.4で部分的に説明されています。これは、短いパケットヘッダーの最初のバイトにスピンビットのみを追加し、将来の使用のために2つの予約ビットを残します（セクション17.2を参照[quic-transport]の.2）。
All signals discussed in this document have been implemented in successful experiments for both QUIC and TCP. The application scenarios considered allow the monitoring of the interconnections inside a data center (Intra-DC), between data centers (Inter-DC), as well as end-to-end large-scale data transfers. For the application of the methods described in this document, it is assumed that the monitored flows follow stable paths and traverse the same measurement points.
このドキュメントで説明されているすべての信号は、QUICとTCPの両方の成功した実験で実装されています。考慮されるアプリケーションシナリオでは、データセンター内の相互接続（DC内）、データセンター（Inter-DC）、およびエンドツーエンドの大規模なデータ転送の監視が可能になります。このドキュメントで説明されている方法を適用するために、監視されたフローは安定したパスに従い、同じ測定ポイントを横断すると想定されています。
The specific implementation details and the choice of the bits used for the experiments with QUIC and TCP are out of scope for this document. A specification defining the specific protocol application is expected to discuss the implementation details depending on which bits will be implemented in the protocol, e.g., [CORE-COAP-PM]. If bits used for specific measurements can also be used for other purposes by a protocol, the specification is expected to address ways for on-path observers to disambiguate the signals or to discuss limitations on the conditions under which the observers can expect a valid signal.
具体的な実装の詳細とQUICおよびTCPの実験に使用されるBITの選択は、このドキュメントの範囲外です。特定のプロトコルアプリケーションを定義する仕様では、プロトコルで実装されるBIT、たとえば[Core-Coap-PM]に応じて、実装の詳細について説明することが期待されます。特定の測定に使用されるBITSがプロトコルによって他の目的にも使用できる場合、仕様は、パスオンパスオブザーバーが信号を非表示にする方法に対処したり、オブザーバーが有効な信号を期待できる条件の制限を議論する方法に対処することが期待されます。
Accurate loss and delay information is not required for the operation of any protocol, though its presence for a sufficient number of flows is important for the operation of networks.
プロトコルの操作には正確な損失と遅延情報は必要ありませんが、ネットワークの動作には十分な数のフローの存在が重要です。
The delay and loss bits are amenable to "greasing" described in [RFC8701] if the protocol designers are not ready to dedicate (and ossify) bits used for loss reporting to this function. The greasing could be accomplished similarly to the latency Spin bit greasing in Section 17.4 of [QUIC-TRANSPORT]. For example, the protocol designers could decide that a fraction of flows should not encode loss and delay information, and instead, the bits would be set to arbitrary values. Setting any of the bits described in this document to arbitrary values would make the corresponding delay and loss information resemble noise rather than the expected signal for the flow, and the observers would need to be ready to ignore such flows.
遅延および損失ビットは、プロトコル設計者がこの機能への損失報告に使用されるビットを専用（およびOSSIFY）する準備ができていない場合、[RFC8701]に記載されている「グリース」に適しています。グリースは、[Quic-Transport]のセクション17.4では、レイテンシスピンビットと同様に達成できます。たとえば、プロトコル設計者は、フローの一部が損失情報をエンコードして遅延情報をエンコードしてはならず、代わりにビットが任意の値に設定されることを決定できます。このドキュメントで説明されているBITのいずれかを任意の値に設定すると、対応する遅延情報と損失情報がフローの予想信号ではなくノイズに似ています。
The methods described in this document are transport agnostic and potentially applicable to any transport-layer protocol, and especially valuable for encrypted protocols. These methods can be applied to both limited domains and the Internet, depending on the specific protocol application.
このドキュメントで説明されている方法は、輸送不可知論者であり、あらゆる輸送層プロトコルに潜在的に適用可能であり、特に暗号化されたプロトコルにとって価値があります。これらの方法は、特定のプロトコルアプリケーションに応じて、限られたドメインとインターネットの両方に適用できます。
Passive loss and delay observations have been a part of the network operations for a long time, so exposing loss and delay information to the network does not add new security concerns for protocols that are currently observable.
パッシブ損失と遅延の観察は長い間ネットワーク操作の一部であるため、損失情報と遅延情報をネットワークに公開しても、現在観察可能なプロトコルに新しいセキュリティ上の懸念が追加されません。
In the absence of packet loss, Q and R bits signals do not provide any information that cannot be observed by simply counting packets transiting a network path. In the presence of packet loss, Q and R bits will disclose the loss, but this is information about the environment and not the endpoint state. The L bit signal discloses internal state of the protocol's loss-detection machinery, but this state can often be gleaned by timing packets and observing the congestion controller response.
パケットの損失がない場合、QおよびR BITS信号は、ネットワークパスを通過するパケットをカウントするだけでは観察できない情報を提供しません。パケットの損失が存在する場合、QおよびRビットは損失を開示しますが、これはエンドポイントの状態ではなく、環境に関する情報です。Lビット信号は、プロトコルの損失検出機械の内部状態を開示しますが、この状態は、タイミングパケットと混雑コントローラーの応答を観察することで収集することがよくあります。
The measurements described in this document do not imply that new packets injected into the network can cause potential harm to the network itself and to data traffic. The measurements could be harmed by an attacker altering the marking of the packets or injecting artificial traffic. Authentication techniques may be used where appropriate to guard against these traffic attacks.
このドキュメントで説明されている測定値は、ネットワークに注入された新しいパケットがネットワーク自体とデータトラフィックに潜在的な害を引き起こす可能性があることを意味しません。測定値は、攻撃者がパケットのマーキングを変更したり、人工交通を注入することで害を受ける可能性があります。これらのトラフィック攻撃を防ぐために、適切に認証技術を使用することができます。
Hence, loss bits do not provide a viable new mechanism to attack data integrity and secrecy.
したがって、損失ビットは、データの整合性と秘密を攻撃するための実行可能な新しいメカニズムを提供しません。
The measurement fields introduced in this document are intended to be included in the packets. However, it is worth mentioning that it may be possible to use this information as a covert channel.
このドキュメントで導入された測定フィールドは、パケットに含まれることを目的としています。ただし、この情報を秘密のチャネルとして使用することが可能である可能性があることに言及する価値があります。
This document does not define a specific application, and the described techniques can generally apply to different communication protocols operating in different security environments. A specification defining a specific protocol application is expected to address the respective security considerations and must consider specifics of the protocol and its expected operating environment. For example, security considerations for QUIC, discussed in Section 21 of [QUIC-TRANSPORT] and Section 9 of [QUIC-TLS], consider a possibility of active and passive attackers in the network as well as attacks on specific QUIC mechanisms.
このドキュメントは特定のアプリケーションを定義するものではなく、説明された手法は一般に、さまざまなセキュリティ環境で動作するさまざまな通信プロトコルに適用できます。特定のプロトコルアプリケーションを定義する仕様は、それぞれのセキュリティに関する考慮事項に対処することが期待されており、プロトコルとその予想される動作環境の詳細を考慮する必要があります。たとえば、[QUIC-Transport]のセクション21および[QUIC-TLS]のセクション9で説明したQUICのセキュリティ上の考慮事項は、ネットワーク内のアクティブおよびパッシブ攻撃者の可能性と特定のQUICメカニズムへの攻撃を検討します。
A defense against an optimistic ACK attack, described in Section 21.4 of [QUIC-TRANSPORT], involves a sender randomly skipping packet numbers to detect a receiver acknowledging packet numbers that have never been received. The Q bit signal may inform the attacker which packet numbers were skipped on purpose and which had been actually lost (and are, therefore, safe for the attacker to acknowledge). To use the Q bit for this purpose, the attacker must first receive at least an entire Q Block of packets, which renders the attack ineffective against a delay-sensitive congestion controller.
[QUIC-Transport]のセクション21.4で説明されている楽観的なACK攻撃に対する防御には、送信者がランダムにパケット番号をスキップして、受信したことのないパケット番号を確認するレシーバーを検出することが含まれます。Qビット信号は、攻撃者に、どのパケット番号が意図的にスキップされ、実際に失われたことを通知する場合があります（したがって、攻撃者が認めるのは安全です）。この目的のためにQビットを使用するには、攻撃者は最初に少なくともQブロックのパケットの全体を受け取る必要があります。これにより、攻撃は遅延に敏感な混雑コントローラーに対して効果がありません。
A protocol that is more susceptible to an optimistic ACK attack with the loss signal provided by the Q bit and that uses a loss-based congestion controller should shorten the current Q Block by the number of skipped packets numbers. For example, skipping a single packet number will invert the square signal one outgoing packet sooner.
Q BITによって提供される損失信号を使用して楽観的なACK攻撃の影響を受けやすく、損失ベースの混雑コントローラーを使用するプロトコルは、現在のQブロックをスキップしたパケット数の数だけ短縮するはずです。たとえば、単一のパケット番号をスキップすると、正方形の信号が1つの発信パケットをより早く反転させます。
Similar considerations apply to the R bit, although a shortened Reflection Block along with a matching skip in packet numbers does not necessarily imply a lost packet, since it could be due to a lost packet on the reverse path along with a deliberately skipped packet by the sender.
同様の考慮事項はRビットに適用されますが、パケット番号の一致するスキップとともに短縮された反射ブロックは必ずしもパケットの紛失を意味するわけではありません。送信者。
Theoretically, delay measurements can be used to roughly evaluate the distance of the client from the server (using the RTT) or from any intermediate observer (using the client-observer half-RTT). As described in [RTT-PRIVACY], connection RTT measurements for geolocating endpoints are usually inferior to even the most basic IP geolocation databases. It is the variability within RTT measurements (the jitter) that is most informative, as it can provide insight into the operating environment of the endpoints as well as the state of the networks (queuing delays) used by the connection.
理論的には、遅延測定を使用して、サーバー（RTTを使用）または中間オブザーバー（クライアントオーバーバーハーフRTTを使用）からクライアントの距離を大まかに評価できます。[RTT-Privacy]で説明されているように、地理的エンドポイントの接続RTT測定は通常、最も基本的なIPジオロケーションデータベースよりも劣ります。エンドポイントの操作環境と、接続で使用されるネットワークの状態（キューイングの遅延）についての洞察を提供できるのは、最も有益なRTT測定（ジッター）内の変動性です。
Nevertheless, to further mask the actual RTT of the connection, the Delay bit algorithm can be slightly modified by, for example, delaying the client-side reflection of the delay sample by a fixed, randomly chosen time value. This would lead an intermediate observer to measure a delay greater than the real one.
それにもかかわらず、接続の実際のRTTをさらにマスクするために、たとえば、遅延サンプルのクライアント側の反射が固定されたランダムに選択された時間値でクライアント側の反射を遅らせることにより、遅延ビットアルゴリズムをわずかに変更できます。これにより、中間観測者が実際のオブザーバーよりも大きな遅延を測定するようになります。
This Additional Delay should be randomly selected by the client and kept constant for a certain amount of time across multiple connections. This ensures that the client-server jitter remains the same as if no Additional Delay had been inserted. For example, a new Additional Delay value could be generated whenever the client's IP address changes.
この追加の遅延は、クライアントがランダムに選択し、複数の接続にわたって一定の時間を一定に保つ必要があります。これにより、クライアントサーバージッターが追加の遅延が挿入されていない場合と同じままであることが保証されます。たとえば、クライアントのIPアドレスが変更されるたびに、新しい追加の遅延値を生成できます。
Despite the Additional Delay, this Hidden Delay technique still allows an accurate measurement of the RTT components (observer-server) and all the intra-domain measurements used to distribute the delay in the network. Furthermore, unlike the Delay bit, the Hidden Delay bit does not require the use of the client reflection threshold (1 ms by default). Removing this threshold may lead to increasing the number of valid measurements produced by the algorithm.
追加の遅延にもかかわらず、この隠された遅延手法により、RTTコンポーネント（Observer-Server）の正確な測定と、ネットワークの遅延の分布に使用されるすべてのドメイン測定が可能になります。さらに、遅延ビットとは異なり、隠された遅延ビットでは、クライアントリフレクションのしきい値を使用する必要はありません（デフォルトでは1ミリ秒）。このしきい値を削除すると、アルゴリズムによって生成される有効な測定の数が増える可能性があります。
Note that the Hidden Delay bit does not affect an observer's ability to measure accurate RTT using other means, such as timing packets exchanged during the connection establishment.
隠された遅延ビットは、接続確立中に交換されるタイミングパケットなど、他の手段を使用して正確なRTTを測定するオブザーバーの能力に影響しないことに注意してください。
To minimize unintentional exposure of information, loss bits provide an explicit loss signal -- a preferred way to share information per [RFC8558].
情報の意図しない露出を最小限に抑えるために、損失ビットは明示的な損失信号を提供します。これは、[RFC8558]ごとに情報を共有する優先方法です。
New protocols commonly have specific privacy goals, and loss reporting must ensure that loss information does not compromise those privacy goals. For example, [QUIC-TRANSPORT] allows changing Connection IDs in the middle of a connection to reduce the likelihood of a passive observer linking old and new sub-flows to the same device (see Section 5.1 of [QUIC-TRANSPORT]). A QUIC implementation would need to reset all counters when it changes the destination (IP address or UDP port) or the Connection ID used for outgoing packets. It would also need to avoid incrementing the Unreported Loss counter for loss of packets sent to a different destination or with a different Connection ID.
一般に、新しいプロトコルには特定のプライバシー目標があり、損失の報告には、損失情報がこれらのプライバシー目標を損なうことのないことを保証する必要があります。たとえば、[Quic-Transport]により、接続の途中で接続IDを変更して、古いサブフローと新しいサブフローを同じデバイスにリンクする可能性を減らすことができます（[Quic-Transport]のセクション5.1を参照）。QUIC実装では、宛先（IPアドレスまたはUDPポート）または発信パケットに使用される接続IDを変更すると、すべてのカウンターをリセットする必要があります。また、別の宛先または別の接続IDで送信されたパケットの損失のために、報告されていない損失カウンターの増加を避ける必要があります。
It is also worth highlighting that, if these techniques are not widely deployed, an endpoint that uses them may be fingerprinted based on their usage. However, since there is no release of user data, the techniques seem unlikely to substantially increase the existing privacy risks.
また、これらの手法が広く展開されていない場合、それらを使用するエンドポイントは、使用に基づいてフィンガープリントされる可能性があることを強調する価値があります。ただし、ユーザーデータのリリースがないため、この手法は既存のプライバシーリスクを大幅に増加させる可能性は低いようです。
Furthermore, if there is experimental traffic with these bits set on the network, a network operator could potentially prioritize this marked traffic by placing it in a priority queue. This may result in the delivery of better service, which could potentially mislead an experiment intended to benchmark the network.
さらに、ネットワーク上にこれらのビットが設定された実験トラフィックがある場合、ネットワークオペレーターは、優先キューに配置することにより、このマークされたトラフィックを優先順位付けする可能性があります。これにより、より良いサービスが提供される可能性があり、ネットワークのベンチマークを目的とした実験を誤解させる可能性があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[IPPM-METHODS]
Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.
[TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[ACCURATE-ECN]
Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More
Accurate Explicit Congestion Notification (ECN) Feedback
in TCP", Work in Progress, Internet-Draft, draft-ietf-
tcpm-accurate-ecn-26, 24 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-
accurate-ecn-26>.
[AltMark] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[ANRW19-PM-QUIC]
Bulgarella, F., Cociglio, M., Fioccola, G., Marchetto, G.,
and R. Sisto, "Performance measurements of QUIC
communications", Proceedings of the Applied Networking
Research Workshop (ANRW '19), Association for Computing
Machinery, DOI 10.1145/3340301.3341127, July 2019,
<https://doi.org/10.1145/3340301.3341127>.
[ConEx] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015,
<https://www.rfc-editor.org/info/rfc7713>.
[ConEx-TCP]
Kuehlewind, M., Ed. and R. Scheffenegger, "TCP
Modifications for Congestion Exposure (ConEx)", RFC 7786,
DOI 10.17487/RFC7786, May 2016,
<https://www.rfc-editor.org/info/rfc7786>.
[CORE-COAP-PM]
Fioccola, G., Zhou, T., Nilo, M., Milan, F., and F.
Bulgarella, "Constrained Application Protocol (CoAP)
Performance Measurement Option", Work in Progress,
Internet-Draft, draft-ietf-core-coap-pm-01, 19 October
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
core-coap-pm-01>.
[IPPM-SPIN]
Trammell, B., Ed., "An Explicit Transport-Layer Signal for
Hybrid RTT Measurement", Work in Progress, Internet-Draft,
draft-trammell-ippm-spin-00, 9 January 2019,
<https://datatracker.ietf.org/doc/html/draft-trammell-
ippm-spin-00>.
[IPv6AltMark]
Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
[QUIC-MANAGEABILITY]
Kühlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
September 2022, <https://www.rfc-editor.org/info/rfc9312>.
[QUIC-SPIN]
Trammell, B., Ed., De Vaere, P., Even, R., Fioccola, G.,
Fossati, T., Ihlar, M., Morton, A., and S. Emile, "Adding
Explicit Passive Measurability of Two-Way Latency to the
QUIC Transport Protocol", Work in Progress, Internet-
Draft, draft-trammell-quic-spin-03, 14 May 2018,
<https://datatracker.ietf.org/doc/html/draft-trammell-
quic-spin-03>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/info/rfc8701>.
[RTT-PRIVACY]
Trammell, B. and M. Kühlewind, "Revisiting the Privacy
Implications of Two-Way Internet Latency Data", Passive
and Active Measurement, pp. 73-84, Springer International
Publishing, DOI 10.1007/978-3-319-76481-8_6,
ISBN 9783319764801, March 2018,
<https://doi.org/10.1007/978-3-319-76481-8_6>.
[TRANSPORT-ENCRYPT]
Fairhurst, G. and C. Perkins, "Considerations around
Transport Header Confidentiality, Network Operations, and
the Evolution of Internet Transport Protocols", RFC 9065,
DOI 10.17487/RFC9065, July 2021,
<https://www.rfc-editor.org/info/rfc9065>.
[TSVWG-SPIN]
Trammell, B., Ed., "A Transport-Independent Explicit
Signal for Hybrid RTT Measurement", Work in Progress,
Internet-Draft, draft-trammell-tsvwg-spin-00, 2 July 2018,
<https://datatracker.ietf.org/doc/html/draft-trammell-
tsvwg-spin-00>.
[UDP-OPTIONS]
Touch, J., "Transport Options for UDP", Work in Progress,
Internet-Draft, draft-ietf-tsvwg-udp-options-23, 15
September 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-tsvwg-udp-options-23>.
[UDP-SURPLUS]
Herbert, T., "UDP Surplus Header", Work in Progress,
Internet-Draft, draft-herbert-udp-space-hdr-01, 8 July
2019, <https://datatracker.ietf.org/doc/html/draft-
herbert-udp-space-hdr-01>.
The authors would like to thank the QUIC WG for their contributions, Christian Huitema for implementing Q and L bits in his picoquic stack, and Ike Kunze for providing constructive reviews and helpful suggestions.
著者は、QUIC WGの貢献、Picoquic StackにQおよびLビットを実装してくれたChristian Huitema、および建設的なレビューと有益な提案を提供してくれたIke Kunzeに感謝したいと思います。
The following people provided valuable contributions to this document:
次の人々は、この文書に貴重な貢献を提供しました。
Marcus Ihlar
Ericsson
Email: marcus.ihlar@ericsson.com
Jari Arkko
Ericsson
Email: jari.arkko@ericsson.com
Emile Stephan
Orange
Email: emile.stephan@orange.com
Dmitri Tikhonov
LiteSpeed Technologies
Email: dtikhonov@litespeedtech.com
Mauro Cociglio
Telecom Italia - TIM
Via Reiss Romoli, 274
10148 Torino
Italy
Email: mauro.cociglio@outlook.com
Alexandre Ferrieux
Orange Labs
Email: alexandre.ferrieux@orange.com
Giuseppe Fioccola
Huawei Technologies
Riesstrasse, 25
80992 Munich
Germany
Email: giuseppe.fioccola@huawei.com
Igor Lubashev
Akamai Technologies
Email: ilubashe@akamai.com
Fabio Bulgarella
Telecom Italia - TIM
Via Reiss Romoli, 274
10148 Torino
Italy
Email: fabio.bulgarella@guest.telecomitalia.it
Massimo Nilo
Telecom Italia - TIM
Via Reiss Romoli, 274
10148 Torino
Italy
Email: massimo.nilo@telecomitalia.it
Isabelle Hamchaoui
Orange Labs
Email: isabelle.hamchaoui@orange.com
Riccardo Sisto
Politecnico di Torino
Email: riccardo.sisto@polito.it