[要約] RFC 8802は、Quality for Service (Q4S) Protocolに関する標準仕様であり、リアルタイム通信の品質を測定・制御するためのプロトコルです。このプロトコルの目的は、ネットワーク上での遅延、ジッタ、パケット損失などのパフォーマンスを監視し、品質を維持することです。
Independent Submission J.J. Aranda
Request for Comments: 8802 M. Cortés
Category: Informational Nokia
ISSN: 2070-1721 J. Salvachúa
Univ. Politecnica de Madrid
M. Narganes
Tecnalia
I. Martínez-Sarriegui
Optiva Media
July 2020
The Quality for Service (Q4S) Protocol
Quality for Service（Q4S）プロトコル
Abstract
概要
This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on the HyperText Transfer Protocol (HTTP) and the Session Description Protocol (SDP). The Quality for Service (Q4S) protocol provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet loss, and to alert whenever one of the negotiated conditions is violated.
このメモは、ハイパーテキスト転送プロトコル（HTTP）とセッション記述プロトコル（SDP）に基づくエンドツーエンドのQoS準拠情報の通信のためのアプリケーションレベルのプロトコルについて説明しています。 Quality for Service（Q4S）プロトコルは、待ち時間、ジッター、帯域幅、およびパケット損失をネゴシエートして監視し、ネゴシエートされた条件のいずれかに違反した場合に警告するメカニズムを提供します。
Implementation details on the actions to be triggered upon reception/ detection of QoS alerts exchanged by the protocol are out of scope of this document; it is either application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile).
プロトコルによって交換されるQoSアラートの受信/検出時にトリガーされるアクションの実装の詳細は、このドキュメントの範囲外です。これは、アプリケーションに依存する（たとえば、品質を上げる、またはビットレートを下げる）か、ネットワークに依存する（たとえば、接続の品質プロファイルを変更する）のいずれかです。
This protocol specification is the product of research conducted over a number of years; it is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus.
このプロトコル仕様は、長年にわたって行われた研究の成果です。ここでは永続的な記録として提示され、将来の同様の作業の基礎を提供します。これは標準プロトコルを表すものではなく、IETFの合意もありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは関係なく、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8802.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8802で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Scope
1.2. Motivation
1.3. Summary of Features
1.4. Differences from OWAMP/TWAMP
2. Terminology
3. Overview of Operation
4. Q4S Messages
4.1. Requests
4.2. Responses
4.3. Header Fields
4.3.1. Common Q4S Header Fields
4.3.2. Specific Q4S Request Header Fields
4.3.3. Specific Q4S Response Header Fields
4.4. Bodies
4.4.1. Encoding
5. Q4S Method Definitions
5.1. BEGIN
5.2. READY
5.3. PING
5.4. BWIDTH
5.5. Q4S-ALERT
5.6. Q4S-RECOVERY
5.7. CANCEL
6. Response Codes
6.1. 100 Trying
6.2. Success 2xx
6.2.1. 200 OK
6.3. Redirection 3xx
6.4. Request Failure 4xx
6.4.1. 400 Bad Request
6.4.2. 404 Not Found
6.4.3. 405 Method Not Allowed
6.4.4. 406 Not Acceptable
6.4.5. 408 Request Timeout
6.4.6. 413 Request Entity Too Large
6.4.7. 414 Request-URI Too Long
6.4.8. 415 Unsupported Media Type
6.4.9. 416 Unsupported URI Scheme
6.5. Server Failure 5xx
6.5.1. 500 Server Internal Error
6.5.2. 501 Not Implemented
6.5.3. 503 Service Unavailable
6.5.4. 504 Server Time-Out
6.5.5. 505 Version Not Supported
6.5.6. 513 Message Too Large
6.6. Global Failures 6xx
6.6.1. 600 Session Does Not Exist
6.6.2. 601 Quality Level Not Allowed
6.6.3. 603 Session Not Allowed
6.6.4. 604 Authorization Not Allowed
7. Protocol
7.1. Protocol Phases
7.2. SDP Structure
7.2.1. "qos-level" Attribute
7.2.2. "alerting-mode" Attribute
7.2.3. "alert-pause" Attribute
7.2.4. "recovery-pause" Attribute
7.2.5. "public-address" Attributes
7.2.6. "latency" Attribute
7.2.7. "jitter" Attribute
7.2.8. "bandwidth" Attribute
7.2.9. "packetloss" Attribute
7.2.10. "flow" Attributes
7.2.11. "measurement" Attributes
7.2.12. "max-content-length" Attribute
7.3. Measurements
7.3.1. Latency
7.3.2. Jitter
7.3.3. Bandwidth
7.3.4. Packet Loss
7.4. Handshake Phase
7.5. Negotiation Phase
7.5.1. Stage 0: Measurement of Latencies and Jitter
7.5.2. Stage 1: Measurement of Bandwidth and Packet Loss
7.5.3. Quality Constraints Not Reached
7.5.3.1. Actuator Role
7.5.3.2. Policy Server Role
7.5.4. "qos-level" Changes
7.6. Continuity Phase
7.7. Termination Phase
7.7.1. Sanity Check of Quality Sessions
7.8. Dynamic Constraints and Flows
7.9. "qos-level" Upgrade and Downgrade Operation
8. General User Agent Behavior
8.1. Roles in Peer-to-Peer Scenarios
8.2. Multiple Quality Sessions in Parallel
8.3. General Client Behavior
8.3.1. Generating Requests
8.4. General Server Behavior
9. Implementation Recommendations
9.1. Default Client Constraints
9.2. Latency and Jitter Measurements
9.3. Bandwidth Measurements
9.4. Packet Loss Measurement Resolution
9.5. Measurements and Reactions
9.6. Instability Treatments
9.6.1. Loss of Control Packets
9.6.2. Outlier Samples
9.7. Scenarios
9.7.1. Client to ACP
9.7.2. Client to Client
10. Security Considerations
10.1. Confidentiality Issues
10.2. Integrity of Measurements and Authentication
10.3. Privacy of Measurements
10.4. Availability Issues
10.5. Bandwidth Occupancy Issues
11. Future Code Point Requirements
11.1. Service Port
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
The World Wide Web (WWW) is a distributed hypermedia system that has gained widespread acceptance among Internet users. Although WWW browsers support other, preexisting Internet application protocols, the primary protocol used between WWW clients and servers became the HyperText Transfer Protocol (HTTP) ([RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]). Since then, HTTP over TLS (known as HTTPS and described in [RFC2818]) has become an imperative for providing secure and authenticated WWW access. The mechanisms described in this document are equally applicable to HTTP and HTTPS.
ワールドワイドウェブ（WWW）は、インターネットユーザーの間で広く受け入れられている分散ハイパーメディアシステムです。 WWWブラウザは他の既存のインターネットアプリケーションプロトコルをサポートしますが、WWWクライアントとサーバー間で使用される主要なプロトコルは、ハイパーテキスト転送プロトコル（HTTP）（[RFC7230]、[RFC7231]、[RFC7232]、[RFC7233]、[RFC7234]、および[RFC7235]）。それ以来、HTTP over TLS（HTTPSと呼ばれ、[RFC2818]で説明されています）は、安全で認証されたWWWアクセスを提供するために不可欠となっています。このドキュメントで説明するメカニズムは、HTTPとHTTPSに等しく適用できます。
The ease of use of the Web has prompted its widespread employment as a client/server architecture for many applications. Many of such applications require the client and the server to be able to communicate with each other and exchange information with certain quality constraints.
Webの使いやすさにより、多くのアプリケーションのクライアント/サーバーアーキテクチャとして幅広く採用されています。このようなアプリケーションの多くは、クライアントとサーバーが相互に通信し、特定の品質制約のある情報を交換できる必要があります。
Quality in communications at the application level consists of four measurable parameters:
アプリケーションレベルでの通信の品質は、4つの測定可能なパラメーターで構成されます。
Latency: The time a message takes to travel from source to destination. It may be approximated as RTT/2 (round-trip time), assuming the networks are symmetrical. In this context, we will consider the statistical median formula.
待ち時間：メッセージが送信元から宛先に移動するのにかかる時間。ネットワークが対称であると仮定すると、RTT / 2（往復時間）として概算できます。このコンテキストでは、統計的な中央値の式を検討します。
Jitter: Latency variation. There are some formulas to calculate jitter, and in this context, we will consider the arithmetic mean formula.
ジッタ：遅延変動。ジッタの計算にはいくつかの公式があり、このコンテキストでは、算術平均の公式を検討します。
Bandwidth: Bit rate of communication. To ensure quality, a protocol must ensure the availability of the bandwidth needed by the application.
帯域幅：通信のビットレート。品質を保証するために、プロトコルはアプリケーションが必要とする帯域幅の可用性を保証する必要があります。
Packet loss: The percentage of packet loss is closely related to bandwidth and jitter. Packet loss affects bandwidth because a high packet loss sometimes implies retransmissions that also consumes extra bandwidth, other times the retransmissions are not achieved (for example, in video streaming over UDP), and the information received is less than the required bandwidth. In terms of jitter, a packet loss sometimes is seen by the destination as a larger time between arrivals, causing a jitter growth.
パケット損失：パケット損失の割合は、帯域幅とジッターに密接に関連しています。パケット損失は帯域幅に影響を与えます。これは、パケット損失が大きいと再送信が行われて帯域幅が余分に消費されることもあり、再送信が行われない場合（たとえば、UDPを介したビデオストリーミングなど）、受信した情報が必要な帯域幅よりも少ないためです。ジッタに関して、パケット損失は宛先によって到着間のより長い時間として見られることがあり、ジッタの増加を引き起こします。
Any other communication parameter, such as throughput, is not a network parameter because it depends on protocol window size and other implementation-dependent aspects.
スループットなどの他の通信パラメータは、プロトコルウィンドウサイズやその他の実装依存の側面に依存するため、ネットワークパラメータではありません。
The Q4S protocol provides a mechanism for quality monitoring based on an HTTP syntax and the Session Description Protocol (SDP) in order to be easily integrated in the WWW, but it may be used by any type of application, not only those based on HTTP. Quality requirements may be needed by any type of application that communicates using any kind of protocol, especially those with real-time constraints. Depending on the nature of each application, the constraints may be different, leading to different parameter thresholds that need to be met.
Q4Sプロトコルは、WWWに簡単に統合できるように、HTTP構文とセッション記述プロトコル（SDP）に基づく品質監視のメカニズムを提供しますが、HTTPに基づくアプリケーションだけでなく、あらゆる種類のアプリケーションで使用できます。品質要件は、あらゆる種類のプロトコルを使用して通信するあらゆる種類のアプリケーション、特にリアルタイム制約のあるアプリケーションで必要になる場合があります。各アプリケーションの性質に応じて、制約が異なる可能性があり、満たす必要のある異なるパラメーターしきい値につながります。
Q4S is an application-level client/server protocol that continuously measures session quality for a given flow (or set of flows), end-to-end (e2e) and in real time; raising alerts if quality parameters are below a given negotiated threshold and sending recoveries when quality parameters are restored. Q4S describes when these notifications, alerts, and recoveries need to be sent and the entity receiving them. The actions undertaken by the receiver of the alert are out of scope of the protocol.
Q4Sは、特定のフロー（またはフローのセット）のエンドツーエンド（e2e）のセッション品質を継続的にリアルタイムで測定するアプリケーションレベルのクライアント/サーバープロトコルです。品質パラメーターが特定の交渉済みしきい値を下回った場合にアラートを生成し、品質パラメーターが復元されたときに回復を送信します。 Q4Sは、これらの通知、アラート、およびリカバリを送信する必要がある場合と、それらを受信するエンティティについて説明します。アラートの受信者が行うアクションは、プロトコルの範囲外です。
Q4S is session-independent from the application flows to minimize the impact on them. To perform the measurements, two control flows are created on both communication paths (forward and reverse directions).
Q4Sは、アプリケーションフローからの影響を最小限に抑えるために、セッションに依存しません。測定を実行するために、2つの制御フローが両方の通信パス（順方向と逆方向）で作成されます。
This protocol specification is the product of research conducted over a number of years and is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus.
このプロトコル仕様は、何年にもわたって行われた研究の産物であり、永続的な記録としてここに提示され、将来の同様の作業の基礎を提供します。これは標準プロトコルを表すものではなく、IETFの合意もありません。
The purpose of Q4S is to measure end-to-end network quality in real time. Q4S does not transport any application data. This means that Q4S is designed to be used jointly with other transport protocols such as Real-time Transport Protocol (RTP) [RFC3550], Transmission Control Protocol (TCP) [RFC0793], QUIC [QUIC], HTTP [RFC7230], etc.
Q4Sの目的は、エンドツーエンドのネットワーク品質をリアルタイムで測定することです。 Q4Sはアプリケーションデータを転送しません。つまり、Q4Sは、リアルタイムトランスポートプロトコル（RTP）[RFC3550]、伝送制御プロトコル（TCP）[RFC0793]、QUIC [QUIC]、HTTP [RFC7230]などの他のトランスポートプロトコルと組み合わせて使用するように設計されています。
Some existent transport protocols are focused on real-time media transport and certain connection metrics are available, which is the case of RTP and RTP Control Protocol (RTCP) [RFC3550]. Other protocols such as QUIC provide low connection latencies as well as advanced congestion control. These protocols transport data efficiently and provide a lot of functionalities. However, there are currently no other quality measurement protocols offering the same level of function as Q4S. See Section 1.4 for a discussion of the IETF's quality measurement protocols, One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP).
一部の既存のトランスポートプロトコルは、リアルタイムのメディアトランスポートに焦点を当てており、特定の接続メトリックを使用できます。これは、RTPおよびRTPコントロールプロトコル（RTCP）[RFC3550]の場合です。 QUICなどの他のプロトコルは、接続遅延を短縮するだけでなく、高度な輻輳制御も提供します。これらのプロトコルは、データを効率的に転送し、多くの機能を提供します。ただし、Q4Sと同じレベルの機能を提供する他の品質測定プロトコルは現在ありません。 IETFの品質測定プロトコルである一方向アクティブ測定プロトコル（OWAMP）と双方向アクティブ測定プロトコル（TWAMP）については、セクション1.4を参照してください。
Q4S enables applications to become reactive under e2e network quality changes. To achieve it, an independent Q4S stack application must run in parallel with the target application. Then, Q4S metrics may be used to trigger actions on the target application, such as speed adaptation to latency in multiuser games, bitrate control at streaming services, intelligent commutation of delivery node at Content Delivery Networks, and whatever the target application allows.
Q4Sにより、アプリケーションはe2eネットワーク品質の変化に対応できるようになります。これを実現するには、独立したQ4Sスタックアプリケーションをターゲットアプリケーションと並行して実行する必要があります。次に、Q4Sメトリックを使用して、マルチユーザーゲームのレイテンシへの速度の適応、ストリーミングサービスでのビットレート制御、コンテンツ配信ネットワークでの配信ノードのインテリジェントな通信など、ターゲットアプリケーションで許可されているすべてのアクションをターゲットアプリケーションでトリガーできます。
Monitoring quality of service (QoS) in computer networks is useful for several reasons:
コンピュータネットワークでのサービス品質（QoS）の監視は、いくつかの理由で役立ちます。
* It enables real-time services and applications to verify whether network resources achieve a certain QoS level. This helps real-time services and applications to run over the Internet, allowing the existence of Application Content Providers (ACPs), which offer guaranteed real-time services to the end users.
* これにより、リアルタイムサービスとアプリケーションは、ネットワークリソースが特定のQoSレベルを達成しているかどうかを確認できます。これにより、リアルタイムサービスとアプリケーションがインターネット上で実行され、エンドユーザーに保証されたリアルタイムサービスを提供するアプリケーションコンテンツプロバイダー（ACP）の存在が可能になります。
* Real-time monitoring allows applications to adapt themselves to network conditions (application-based QoS) and/or request more network quality from the Internet Service Provider (ISP) (if the ISP offers this possibility).
* リアルタイムの監視により、アプリケーションはネットワーク状態（アプリケーションベースのQoS）に適応したり、インターネットサービスプロバイダー（ISP）にネットワーク品質を要求したりできます（ISPがこの可能性を提供する場合）。
* Monitoring may also be required by peer-to-peer (P2P) real-time applications for which Q4S can be used.
* Q4Sを使用できるピアツーピア（P2P）リアルタイムアプリケーションでも監視が必要になる場合があります。
* Monitoring enables ISPs to offer QoS to any ACP or end user application in an accountable way.
* 監視により、ISPは、ACPまたはエンドユーザーアプリケーションに責任ある方法でQoSを提供できます。
* Monitoring enables e2e negotiation of QoS parameters, independently of the ISPs of both endpoints.
* モニタリングにより、両方のエンドポイントのISPとは関係なく、QoSパラメータのe2eネゴシエーションが可能になります。
A protocol to monitor QoS must address the following issues:
QoSを監視するプロトコルは、次の問題に対処する必要があります。
* Must be ready to be used in conjunction with current standard protocols and applications, without forcing a change on them.
* 現在の標準プロトコルおよびアプリケーションと組み合わせて、それらを強制的に変更せずに使用する準備ができている必要があります。
* Must have a formal and compact way to specify quality constraints desired by the application to run.
* アプリケーションの実行に必要な品質の制約を指定するための正式でコンパクトな方法が必要です。
* Must have measurement mechanisms that avoid application disruption and minimize network resources consumption.
* アプリケーションの中断を回避し、ネットワークリソースの消費を最小限に抑える測定メカニズムが必要です。
* Must have specific messages to alert about the violation of quality constraints in different directions (forward and reverse) because network routing may not be symmetrical, and of course, quality constraints may not be symmetrical.
* ネットワークルーティングが対称的ではない場合があり、もちろん品質制約が対称的でない場合があるため、さまざまな方向（順方向と逆方向）での品質制約の違反について警告する特定のメッセージが必要です。
* After having alerted about the violation of quality constraints, must have specific messages to inform about the recovery of quality constraints in corresponding directions (forward and reverse).
* 品質制約の違反について警告した後、対応する方向（順方向および逆方向）での品質制約の回復について通知する特定のメッセージが必要です。
* Must protect the data (constraints, measurements, QoS levels demanded from the network) in order to avoid the injection of malicious data in the measurements.
* 測定での悪意のあるデータの挿入を回避するために、データ（制約、測定、ネットワークから要求されるQoSレベル）を保護する必要があります。
The Quality for Service (Q4S) protocol is a message-oriented communication protocol that can be used in conjunction with any other application-level protocol. Q4S is a measurement protocol. Any action taken derived from its measurements are out of scope of the protocol. These actions depend on the application provider and may be application-level adaptive reactions, may involve requests to the ISP, or whatever the application provider decides.
Quality for Service（Q4S）プロトコルは、他のアプリケーションレベルのプロトコルと組み合わせて使用できるメッセージ指向の通信プロトコルです。 Q4Sは測定プロトコルです。その測定値から得られたすべてのアクションは、プロトコルの範囲外です。これらのアクションは、アプリケーションプロバイダーに依存し、アプリケーションレベルの適応反応、ISPへの要求、またはアプリケーションプロバイダーが決定したものを含む場合があります。
The benefits in quality measurements provided by Q4S can be used by any type of application that uses any type of protocol for data transport. It provides a quality monitoring scheme for any communication that takes place between the client and the server, not only for the Q4S communication itself.
Q4Sによって提供される品質測定の利点は、データ転送に任意のタイプのプロトコルを使用する任意のタイプのアプリケーションで使用できます。 Q4S通信自体だけでなく、クライアントとサーバー間で行われるすべての通信に品質監視スキームを提供します。
Q4S does not establish multimedia sessions, and it does not transport application data. It monitors the fulfillment of the quality requirements of the communication between the client and the server; therefore, it does not impose any restrictions on the type of application, protocol, or usage of the monitored quality connection.
Q4Sはマルチメディアセッションを確立せず、アプリケーションデータを転送しません。クライアントとサーバー間の通信の品質要件の達成を監視します。したがって、アプリケーションのタイプ、プロトコル、または監視対象の品質の接続の使用に制限はありません。
Some applications may vary their quality requirements dynamically for any given quality parameter. Q4S is able to adapt to the changing application needs, modifying the parameter thresholds to the new values and monitoring the network quality according to the new quality constraints. It will raise alerts if the new constraints are violated.
一部のアプリケーションでは、特定の品質パラメーターに対して品質要件を動的に変える場合があります。 Q4Sは、変化するアプリケーションのニーズに適応し、パラメーターのしきい値を新しい値に変更し、新しい品質の制約に従ってネットワーク品質を監視できます。新しい制約に違反すると、アラートが発生します。
The Q4S session lifetime is composed of four phases with different purposes: Handshake, Negotiation, Continuity, and Termination. Negotiation and Continuity phases perform network parameter measurements per a negotiated measurement procedure. Different measurement procedures could be used inside Q4S, although one default measurement mechanism is needed for compatibility reasons and is the one defined in this document. Basically, Q4S defines how to transport application quality requirements and measurement results between a client and server and how to provide monitoring and alerting, too.
Q4Sセッションのライフタイムは、ハンドシェイク、ネゴシエーション、継続性、終了という異なる目的を持つ4つのフェーズで構成されています。ネゴシエーションおよび継続フェーズでは、ネゴシエートされた測定手順に従ってネットワークパラメータ測定を実行します。 Q4S内ではさまざまな測定手順を使用できますが、互換性の理由からデフォルトの測定メカニズムが1つ必要であり、これはこのドキュメントで定義されています。基本的に、Q4Sは、クライアントとサーバー間でアプリケーションの品質要件と測定結果を転送する方法と、監視とアラートを提供する方法も定義します。
Q4S must be executed just before starting a client-server application that needs a quality connection in terms of latency, jitter, bandwidth, and/or packet loss. Once the client and server have succeeded in establishing communication under quality constraints, the application can start, and Q4S continues measuring and alerting if necessary.
Q4Sは、遅延、ジッター、帯域幅、および/またはパケット損失の点で高品質の接続が必要なクライアント/サーバーアプリケーションを起動する直前に実行する必要があります。クライアントとサーバーが品質の制約の下で通信の確立に成功すると、アプリケーションを開始でき、Q4Sは必要に応じて測定とアラートを続行します。
The quality parameters can be suggested by the client in the first message of the Handshake phase, but it is the server that accepts these parameter values or forces others. The server is in charge of deciding the final values of quality connection.
品質パラメータは、ハンドシェイクフェーズの最初のメッセージでクライアントが提案できますが、これらのパラメータ値を受け入れるか、強制的に他の値にします。サーバーは、接続品質の最終値を決定します。
OWAMP [RFC4656] and TWAMP [RFC5357] are two protocols to measure network quality in terms of RTT, but they have a different goal than Q4S. The main difference is the scope: Q4S is designed to assist reactive applications, whereas OWAMP/TWAMP is designed to measure just network delay.
OWAMP [RFC4656]とTWAMP [RFC5357]は、RTTの観点からネットワーク品質を測定する2つのプロトコルですが、Q4Sとは目標が異なります。主な違いは範囲です。Q4Sはリアクティブアプリケーションを支援するように設計されていますが、OWAMP / TWAMPはネットワーク遅延のみを測定するように設計されています。
The differences can be summarized in the following points:
違いは次の点に要約できます。
* OWAMP and TWAMP are not intended for measuring availability of resources (certain bandwidth availability, for example) but only RTT. However, Q4S is intended for measuring required bandwidth, packet loss, jitter, and latency in both directions. Available bandwidth is not measured by Q4S, but bandwidth required for a specific application is.
* OWAMPとTWAMPは、リソースの可用性（たとえば、特定の帯域幅の可用性）を測定するためのものではなく、RTTのみを測定するためのものです。ただし、Q4Sは、必要な帯域幅、パケット損失、ジッター、両方向の遅延を測定することを目的としています。利用可能な帯域幅はQ4Sでは測定されませんが、特定のアプリケーションに必要な帯域幅は測定されます。
* OWAMP and TWAMP do not have responsivity control (which defines the speed of protocol reactions under network quality changes) because these protocols are designed to measure network performance, not to assist reactive applications, and do not detect the fluctuations of quality within certain time intervals to take reactive actions. However, responsivity control is a key feature of Q4S.
* OWAMPとTWAMPには応答性制御がありません（ネットワーク品質の変化におけるプロトコルの反応速度を定義します）。これらのプロトコルは、ネットワークパフォーマンスを測定するように設計されており、リアクティブアプリケーションを支援せず、特定の時間間隔内で品質の変動を検出しないためです。反応的な行動を取る。ただし、応答性制御はQ4Sの主要な機能です。
* OWAMP and TWAMP are not intended to run in parallel with reactive applications, but the Q4S protocol's goal is to run in parallel and assist reactive applications in making decisions based on Q4S-ALERT packets, which may trigger actions.
* OWAMPとTWAMPはリアクティブアプリケーションと並行して実行することを意図していませんが、Q4Sプロトコルの目標は、並行して実行し、リアクションアプリケーションがQ4S-ALERTパケットに基づいて決定を行うのを支援することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This section introduces the basic operation of Q4S using simple examples. This section is of a tutorial nature and does not contain any normative statements.
このセクションでは、簡単な例を使用してQ4Sの基本的な操作を紹介します。このセクションはチュートリアルの性質のものであり、規範的なステートメントは含まれていません。
The first example shows the basic functions of Q4S: communication establishment between a client and a server, quality requirement negotiations for the requested application, application start and continuous quality parameter measurements, and finally communication termination.
最初の例は、Q4Sの基本機能を示しています。クライアントとサーバー間の通信の確立、要求されたアプリケーションの品質要件交渉、アプリケーションの開始と継続的な品質パラメーター測定、そして最後に通信の終了です。
The client triggers the establishment of the communication by requesting a specific service or application from the server. This first message must have a special URI [RFC3986], which may force the use of the Q4S protocol if it is implemented in a standard web browser. This message consists of a Q4S BEGIN method, which can optionally include a proposal for the communication quality requirements in an SDP body. This option gives the client a certain negotiation capacity about quality requirements, but it will be the server who finally decides the stated requirements.
クライアントは、サーバーから特定のサービスまたはアプリケーションを要求することにより、通信の確立をトリガーします。この最初のメッセージには、特別なURI [RFC3986]が必要です。標準のWebブラウザーに実装されている場合、Q4Sプロトコルの使用を強制する可能性があります。このメッセージはQ4S BEGINメソッドで構成され、オプションでSDP本体に通信品質要件の提案を含めることができます。このオプションは、クライアントに品質要件に関する特定の交渉能力を提供しますが、最終的に指定された要件を決定するのはサーバーです。
This request is answered by the server with a Q4S 200 OK response letting the client know that it accepts the request. This response message must contain an SDP body with the following:
この要求は、サーバーがQ4S 200 OK応答で応答し、クライアントが要求を受け入れることを通知します。この応答メッセージには、以下のSDP本体が含まれている必要があります。
* The assigned Q4S sess-id.
* 割り当てられたQ4S sess-id。
* The quality constraints required by the requested application.
* 要求されたアプリケーションに必要な品質の制約。
* The measurement procedure to use.
* 使用する測定手順。
* "alerting-mode" attribute: There are two different scenarios for sending alerts that trigger actions either on the network or in the application when measurements identify violated quality constraints. In both cases, alerts are triggered by the server.
* 「アラートモード」属性：測定で違反した品質制約が特定されたときに、ネットワーク上またはアプリケーション内でアクションをトリガーするアラートを送信するには、2つの異なるシナリオがあります。どちらの場合も、アラートはサーバーによってトリガーされます。
(a) Q4S-aware-network scenario: The network is Q4S aware and reacts by itself to these alerts. In this scenario, Q4S-ALERT messages are sent by the server to the client, and network elements inspect and process these alert messages. The alerting mode in this scenario is called Q4S-aware-network alerting mode.
（a）Q4S対応ネットワークシナリオ：ネットワークはQ4S対応であり、これらのアラートに単独で反応します。このシナリオでは、Q4S-ALERTメッセージがサーバーからクライアントに送信され、ネットワーク要素がこれらのアラートメッセージを検査して処理します。このシナリオのアラートモードは、Q4S対応ネットワークアラートモードと呼ばれます。
(b) Reactive scenario: As shown in Figure 1, the network is not Q4S aware. In this scenario, alert notifications are sent to a specific node, called an Actuator, which is in charge of making decisions regarding what actions to trigger: either to change application behavior to adapt it to network conditions and/or invoke a network policy server in order to reconfigure the network and request better quality for application flows.
（b）反応シナリオ：図1に示すように、ネットワークはQ4S対応ではありません。このシナリオでは、アクチュエータと呼ばれる特定のノードにアラート通知が送信されます。このノードは、トリガーするアクションに関する決定を行います。アプリケーションの動作を変更してネットワークの状態に適応させるか、ネットワークポリシーサーバーを呼び出します。ネットワークを再構成し、アプリケーションフローの品質向上を要求するため。
+------+ +-----------+
| App |<----- app flows---------->|Application|
|Client| +-----------+
+------+ A
|
+------+ +------+ +--------+
| Q4S |<----Q4S---->| Q4S |<----->|Actuator|
|Client| |Server| +--------+
+------+ +------+ |
V
+-------------+
|policy server|
+-------------+
Figure 1: Reactive Scenario
図1：リアクティブシナリオ
The format of messages exchanged between the server stack and the Actuator doesn't follow Q4S codification rules; their format will be implementation dependent. In this way, we will call the messages sent from the server stack to the Actuator "notifications" (e.g., alert notifications) and the messages sent from the Actuator to the server stack in response to notifications "acknowledges" (e.g., alert acknowledges).
サーバースタックとアクチュエータの間で交換されるメッセージの形式は、Q4S体系化ルールに従っていません。それらの形式は実装に依存します。このようにして、サーバースタックからアクチュエータに送信されたメッセージを「通知」（たとえば、アラート通知）と呼び、通知に応答してアクチュエータからサーバースタックに送信されたメッセージ（たとえば、アラート確認）を呼び出します。 。
* "alert-pause" attribute: The amount of time between consecutive alerts. In the Q4S-aware-network scenario, the server has to wait this period of time between Q4S-ALERT messages sent to the client. In the Reactive scenario, the server stack has to wait this period of time between alert notifications sent to the Actuator. Measurements are not stopped in Negotiation or Continuity phases during this period of time, but no alerts are sent, even with violated network quality constraints, in order to leave time for network reconfiguration or for application adjustments.
* 「アラート一時停止」属性：連続するアラート間の時間。 Q4S対応ネットワークのシナリオでは、サーバーは、クライアントに送信されるQ4S-ALERTメッセージの間にこの期間待機する必要があります。リアクティブシナリオでは、サーバースタックは、アクチュエータに送信されるアラート通知の間にこの期間待機する必要があります。この期間中、ネゴシエーションまたは継続フェーズで測定は停止されませんが、ネットワークの再構成やアプリケーションの調整のために時間を確保するために、ネットワーク品質の制約に違反していてもアラートは送信されません。
* "recovery-pause" attribute: The amount of time the Q4S server waits before trying to recover the initial "qos-level" (Section 7.2.1). After having detected violation of quality constraints several times, the "qos-level" will have been increased accordingly. If this violation detection finally stops, the server waits for a period of time (recovery time), and if the situation persists, it tries to recover to previous "qos-level" values gradually by sending Q4S-RECOVERY messages to the client in the Q4S-aware-network scenario, or recovery notifications to the Actuator in the Reactive scenario (Section 7.9).
* "recovery-pause"属性：Q4Sサーバーが最初の "qos-level"を回復しようとする前に待機する時間（セクション7.2.1）。品質制約の違反を数回検出した後、それに応じて「QOSレベル」が増加します。この違反検出が最終的に停止すると、サーバーは一定の時間（回復時間）待機し、状況が続く場合は、Q4S-RECOVERYメッセージをクライアントのクライアントに送信することにより、以前の「QOSレベル」の値に徐々に回復しようとしますQ4S対応ネットワークシナリオ、またはリアクティブシナリオ（セクション7.9）のアクチュエーターへのリカバリー通知。
It is important to highlight that any Q4S 200 OK response sent by the server to the client at any time during the life of a quality session may contain an SDP body with new values of quality constraints required by the application. Depending on the phase and the state of the measurement procedure within the specific phase, the client will react accordingly to take into account the new quality constraints in the measurement procedure.
品質セッションの存続期間中いつでもサーバーからクライアントに送信されるQ4S 200 OK応答には、アプリケーションが必要とする品質制約の新しい値を持つSDP本体が含まれている可能性があることを強調することが重要です。特定のフェーズ内のフェーズと測定手順の状態に応じて、クライアントはそれに応じて対応し、測定手順の新しい品質の制約を考慮します。
Once the communication has been established (i.e., the Handshake phase is finished), the protocol will verify that the communication path between the client and the server meets the quality constraints in both directions, from and to the server (Negotiation phase). This Negotiation phase requires taking measurements of the quality parameters: latencies, jitter, bandwidth, and packet loss. This phase is initiated with a client message containing a Q4S READY method, which will be answered by the server with a Q4S 200 OK response.
通信が確立されると（つまり、ハンドシェイクフェーズが終了すると）、プロトコルは、クライアントとサーバー間の通信パスが、サーバーとの間の双方向の品質制約を満たしていることを確認します（ネゴシエーションフェーズ）。この交渉フェーズでは、待ち時間、ジッター、帯域幅、パケット損失などの品質パラメーターを測定する必要があります。このフェーズは、Q4S READYメソッドを含むクライアントメッセージで開始され、サーバーはQ4S 200 OK応答で応答します。
Negotiation measurements are achieved in two sequential stages:
交渉の測定は、次の2つの段階で行われます。
Stage 0: latency and jitter measurements
ステージ0：レイテンシとジッターの測定
Stage 1: bandwidth and packet loss measurements
ステージ1：帯域幅とパケット損失の測定
Stage 0 measurements are taken through Q4S PING messages sent from both the client and the server. All Q4S PING requests will be answered by Q4S 200 OK messages to allow for bidirectional measurements.
ステージ0の測定は、クライアントとサーバーの両方から送信されたQ4S PINGメッセージを介して行われます。すべてのQ4S PING要求は、双方向測定を可能にするためにQ4S 200 OKメッセージによって応答されます。
Different client and server implementations may send a different number of PING messages for measuring, although at least 255 messages should be considered to perform the latency measurement. The Stage 0 measurements only may be considered ended when neither client nor server receive new PING messages after an implementation-dependent guard time. Only after Stage 0 has ended, can the client send a "READY 1" message.
レイテンシ測定を実行するには少なくとも255メッセージを考慮する必要がありますが、クライアントとサーバーの実装が異なると、測定するPINGメッセージの数も異なります。ステージ0の測定は、実装に依存するガードタイム後にクライアントもサーバーも新しいPINGメッセージを受信しない場合にのみ終了したと見なすことができます。ステージ0が終了した後でのみ、クライアントは「READY 1」メッセージを送信できます。
After a pre-agreed number of measurements have been performed, determined by the measurement procedure sent by the server, three scenarios may be possible:
サーバーによって送信された測定手順によって決定された、事前に合意された数の測定が実行された後、3つのシナリオが可能になる場合があります。
(a) Measurements do not meet the requirements: in this case, the stage 0 is repeated after sending an alert from the server to the client or from the server stack to the Actuator, depending on the alerting mode defined in the Handshake phase. Notice that measurements continue to be taken but no alerts are sent during the "alert-pause" time. In the Reactive scenario, the Actuator will decide either to forward the alert notification to the network policy server or to the application, depending on where reconfiguration actions have to be taken.
（a）測定が要件を満たしていません。この場合、ハンドシェイクフェーズで定義されたアラートモードに応じて、サーバーからクライアントまたはサーバースタックからアクチュエータにアラートを送信した後、ステージ0が繰り返されます。測定は引き続き行われますが、「アラートの一時停止」の間はアラートが送信されないことに注意してください。リアクティブシナリオでは、アクチュエータは、再構成アクションを実行する必要がある場所に応じて、アラート通知をネットワークポリシーサーバーまたはアプリケーションのどちらに転送するかを決定します。
(b) Measurements do meet the requirements: in this case, client moves to stage 1 by sending a new READY message.
（b）測定は要件を満たしています。この場合、クライアントは新しいREADYメッセージを送信してステージ1に移動します。
(c) At any time during the measurement procedure, the Q4S 200 OK message sent by the server to the client, in response to a Q4S PING message, contains an SDP body with new values of quality constraints required by the application. This means the application has varied their quality requirements dynamically; therefore, quality thresholds used while monitoring quality parameters have to be changed to the new constraints. In this case, the client moves to the beginning of Stage 0 for initiating the negotiation measurements again.
（c）測定手順中のいつでも、Q4S PINGメッセージに応答してサーバーからクライアントに送信されたQ4S 200 OKメッセージには、アプリケーションで必要な品質制約の新しい値を含むSDP本体が含まれます。これは、アプリケーションが品質要件を動的に変化させたことを意味します。したがって、品質パラメータの監視中に使用される品質しきい値は、新しい制約に変更する必要があります。この場合、クライアントはステージ0の最初に移動して、ネゴシエーション測定を再度開始します。
Stage 1 is optional. Its purpose is to measure the availability of application-needed bandwidth. If the "bandwidth" attribute is set to zero kbps in the SDP, the client can skip stage 1 by sending a "READY 2" message after completion of stage 0. Stage 1 measurements are achieved through Q4S BWIDTH messages sent from both the client and the server. Unlike PING messages, Q4S BWIDTH requests will not be answered.
ステージ1はオプションです。その目的は、アプリケーションが必要とする帯域幅の可用性を測定することです。 SDPで「帯域幅」属性がゼロkbpsに設定されている場合、クライアントはステージ0の完了後に「READY 2」メッセージを送信することにより、ステージ1をスキップできます。ステージ1の測定は、クライアントとクライアントの両方から送信されたQ4S BWIDTHメッセージによって行われます。サーバー。 PINGメッセージとは異なり、Q4S BWIDTHリクエストは応答されません。
If Stage 0 and 1 meet the application quality constraints, the application may start. Q4S will enter the Continuity phase by measuring the network quality parameters through the Q4S PING message exchange on both connection paths and raising alerts in case of violation.
ステージ0と1がアプリケーション品質の制約を満たす場合、アプリケーションが起動することがあります。 Q4Sは、両方の接続パスでQ4S PINGメッセージ交換を介してネットワーク品質パラメーターを測定し、違反の場合はアラートを発生させることにより、継続フェーズに入ります。
Once the client wants to terminate the quality session, it sends a Q4S CANCEL message, which will be acknowledged by the server with another Q4S CANCEL message. Termination of quality sessions are always initiated by the client because Q4S TCP requests follow the client/server schema.
クライアントは、品質セッションを終了する必要があると、Q4S CANCELメッセージを送信します。これは、サーバーによって別のQ4S CANCELメッセージで確認されます。 Q4S TCP要求はクライアント/サーバースキーマに従うため、品質セッションの終了は常にクライアントによって開始されます。
Figure 2 depicts the message exchange in a successful scenario.
図2は、成功したシナリオでのメッセージ交換を示しています。
+-------------------------------------------+
| |
| Client Server |
| |
Handshake | --------- Q4S BEGIN -----------> |
| <-------- Q4S 200 OK ----------- |
| |
Negotiation | |
(Stage 0) | --------- Q4S READY 0----------> |
| <-------- Q4S 200 OK ----------- |
| |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| --------- Q4S PING ------------> |
| <-------- Q4S PING ------------- |
| --------- Q4S 200 OK ----------> |
| <-------- Q4S 200 OK ----------- |
| ... |
Negotiation | |
(Stage 1) | --------- Q4S READY 1----------> |
| <-------- Q4S 200 OK ----------- |
| |
| --------- Q4S BWITDH ----------> |
| <-------- Q4S BWIDTH------------ |
| --------- Q4S BWITDH ----------> |
| <-------- Q4S BWIDTH------------ |
| ... |
Continuity | --------- Q4S READY 2 ---------> |
| <-------- Q4S 200 OK ----------- | app start
| |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| |
Termination | --------- Q4S CANCEL ----------> | app end
| <-------- Q4S CANCEL ----------- |
| |
+-------------------------------------------+
Figure 2: Successful Q4S Message Exchange
図2：成功したQ4Sメッセージ交換
Both client and server measurements are included in the PING and BWIDTH messages, allowing both sides of the communication channel to be aware of all measurements in both directions.
クライアントとサーバーの両方の測定値がPINGメッセージとBWIDTHメッセージに含まれているため、通信チャネルの両側で両方向のすべての測定値を認識できます。
The following two examples show the behavior of the Q4S protocol when quality constraints are violated, and alerts are generated; and, later on, when the violation of quality constraints stops leading to the execution of the recovery process. The first example (Figure 3) shows the Q4S-aware-network alerting mode scenario:
次の2つの例は、品質の制約に違反し、アラートが生成された場合のQ4Sプロトコルの動作を示しています。後で、品質制約の違反が停止し、回復プロセスの実行につながる場合。最初の例（図3）は、Q4S対応ネットワークアラートモードのシナリオを示しています。
+-------------------------------------------+
| |
| Client Server |
| |
Handshake | --------- Q4S BEGIN -----------> |
| <-------- Q4S 200 OK ----------- |
| |
Negotiation | |
(Stage 0) | --------- Q4S READY 0----------> |
| <-------- Q4S 200 OK ----------- |
| |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| ... |
| |
| <-------- Q4S-ALERT ------------ |
| -------- Q4S-ALERT ------------> |
| (alert-pause start) |
Repetition | |
of Stage 0 | --------- Q4S READY 0----------> |
| <-------- Q4S 200 OK ----------- |
| |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| ... |
Negotiation | |
(Stage 1) | --------- Q4S READY 1----------> |
| <-------- Q4S 200 OK ----------- |
| |
| --------- Q4S BWITDH ----------> |
| <-------- Q4S BWIDTH------------ |
| ... |
| |
Continuity | --------- Q4S READY 2 ---------> |
| <-------- Q4S 200 OK ----------- | app start
| |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| ... |
|(alert-pause expires & |
| violated constraints) |
| <-------- Q4S-ALERT ------------ |
| --------- Q4S-ALERT -----------> |
| |
| (alert-pause start) |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| --------- Q4S 200 OK ----------> |
| ... |
|(alert-pause expires & |
| violated constraints) |
| <-------- Q4S-ALERT ------------ |
| --------- Q4S-ALERT -----------> |
| (alert-pause) |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| ... |
|(alert-pause expires & |
| Fulfilled constraints) |
| |
| (recovery-pause start) |
| |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| ... |
|(recovery-pause expires & |
| Fulfilled constraints) |
| <--------- Q4S-RECOVERY --------- |
| -------- Q4S-RECOVERY -----------> |
| |
| (recovery-pause start) |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| ... |
| |
Termination | --------- Q4S CANCEL ----------> | app end
| <-------- Q4S CANCEL ----------- |
| |
+-------------------------------------------+
Figure 3: Q4S-Aware-Network Alerting Mode
図3：Q4S対応ネットワークアラートモード
In this Q4S-aware-network alerting mode scenario, the server may send Q4S alerts to the client at any time upon detection of violated quality constraints. This alerting exchange must not interrupt the continuity quality parameter measurements between client and server.
このQ4S対応ネットワークアラートモードのシナリオでは、違反した品質制約が検出されると、サーバーはいつでもクライアントにQ4Sアラートを送信できます。このアラート交換により、クライアントとサーバー間の導通品質パラメーターの測定が中断してはなりません。
The second example depicted in Figure 4 represents the Reactive scenario, in which alert notifications are sent from the server stack to the Actuator, which is in charge of deciding to act over application behavior and/or to invoke a network policy server. The Actuator is an entity that has a defined set of different quality levels and decides how to act depending on the actions stated for each of these levels; it can take actions for making adjustments on the application, or it can send a request to the policy server for acting on the network. The policy server also has a defined set of different quality levels previously agreed upon between the Application Content Provider and the ISP. The Reactive alerting mode is the default mode.
図4に示す2番目の例は、サーバースタックからアクチュエータにアラート通知が送信されるリアクティブシナリオを表しています。これは、アプリケーションの動作を介して動作するか、ネットワークポリシーサーバーを呼び出すかを決定します。アクチュエータは、さまざまな品質レベルのセットが定義されたエンティティであり、これらの各レベルについて述べられているアクションに応じて、どのように行動するかを決定します。アプリケーションを調整するためのアクションを実行したり、ネットワーク上で動作するようにリクエストをポリシーサーバーに送信したりできます。ポリシーサーバーには、アプリケーションコンテンツプロバイダーとISPの間で事前に合意された一連の定義済みの異なる品質レベルもあります。リアクティブアラートモードがデフォルトのモードです。
+-------------------------------------------+
| |
| Client Server Actuator |
Handshake | ----- Q4S BEGIN -----> |
| <---- Q4S 200 OK ----- |
| |
Negotiation | |
(Stage 0) | ----- Q4S READY 0----> |
| <---- Q4S 200 OK ----- |
| |
| ----- Q4S PING ------> |
| <---- Q4S 200 OK ----- |
| <---- Q4S PING ------- |
| ---- Q4S 200 OK ----> |
| ... |
| (alert-pause start) |
| --alert |
| notification--> |
| |
| <--alert |
| acknowledge--- |
| |
Repetition | |
of Stage 0 | ----- Q4S READY 0----> |
| <---- Q4S 200 OK ----- |
| |
| ----- Q4S PING ------> |
| <---- Q4S 200 OK ----- |
| <---- Q4S PING ------- |
| ... |
|(alert-pause expires & |
| violated constraints) |
| |
| --alert |
| notification--> |
| |
| <--alert |
| acknowledge--- |
| |
| ----- Q4S PING ------> |
| <---- Q4S 200 OK ----- |
| <---- Q4S PING ------- |
| ... |
Negotiation | |
(Stage 1) | ----- Q4S READY 1----> |
| <---- Q4S 200 OK ----- |
| |
| ----- Q4S BWITDH ----> |
| <---- Q4S BWIDTH------ |
| ... |
Continuity | ----- Q4S READY 2 ---> |
| <---- Q4S 200 OK ----- | app start
| |
|(alert-pause expires & |
| fulfilled constraints) |
| |
|(recovery-pause start) |
| ----- Q4S PING ------> |
| <---- Q4S 200 OK ----- |
| <---- Q4S PING ------- |
| ----- Q4S PING ------> |
| |
|(recovery-pause expires & |
| fulfilled constraints) |
| |
| --recovery |
| notification--> |
| |
| <--recovery |
| acknowledge--- |
| |
|(recovery-pause start) |
| <---- Q4S 200 OK ----- |
| <---- Q4S PING ------- |
| ----- Q4S 200 OK ----> |
| ----- Q4S PING ------> |
| ... |
| |
Termination | ----- Q4S CANCEL ----> | app end
| --cancel |
| notification--> |
| |
| <--cancel |
| acknowledge-- |
| <---- Q4S CANCEL ----- |
| |
+-------------------------------------------+
Figure 4: Reactive Alerting Mode
図4：リアクティブアラートモード
At the end of any stage of the Negotiation phase, the server sends an alert notification to the Actuator if quality constraints are violated. During the period of time defined by the "alert-pause" attribute, no further alert notifications are sent, but measurements are not interrupted. This way, both the client and the server will detect network improvements as soon as possible. In a similar way during the Continuity phase, the server may send alert notifications at any time to the Actuator upon detection of violated quality constraints. This alerting exchange must not interrupt the continuity measurements between client and server.
ネゴシエーションフェーズのいずれかの段階の最後に、品質の制約に違反した場合、サーバーはアラート通知をアクチュエータに送信します。 「alert-pause」属性で定義された期間中は、それ以上のアラート通知は送信されませんが、測定は中断されません。このようにして、クライアントとサーバーの両方ができるだけ早くネットワークの改善を検出します。継続性フェーズ中の同様の方法で、サーバーは違反した品質制約の検出時にいつでもアクチュエーターにアラート通知を送信できます。このアラート交換は、クライアントとサーバー間の連続性測定を中断してはなりません。
Finally, in the Termination phase, Q4S CANCEL messages sent from the client to the server must be forwarded from the server to the Actuator in order to release possible assigned resources for the session.
最後に、終了フェーズでは、セッションに割り当てられた可能性のあるリソースを解放するために、クライアントからサーバーに送信されたQ4S CANCELメッセージをサーバーからアクチュエータに転送する必要があります。
Q4S is a text-based protocol and uses the UTF-8 charset [RFC3629]. A Q4S message is either a request or a response.
Q4Sはテキストベースのプロトコルであり、UTF-8文字セット[RFC3629]を使用します。 Q4Sメッセージは、要求または応答のいずれかです。
Both request and response messages use the basic format of Internet Message Format [RFC5322]. Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body. This document uses ABNF notation [RFC5234] for the definitions of the syntax of messages.
要求メッセージと応答メッセージはどちらも、インターネットメッセージ形式[RFC5322]の基本形式を使用します。どちらのタイプのメッセージも、開始行、1つ以上のヘッダーフィールド、ヘッダーフィールドの終わりを示す空の行、およびオプションのメッセージ本文で構成されます。このドキュメントでは、メッセージの構文の定義にABNF表記[RFC5234]を使用しています。
The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not.
開始行、各メッセージヘッダー行、および空の行は、復帰改行シーケンス（CRLF）で終了する必要があります。メッセージ本文がない場合でも、空の行が存在する必要があることに注意してください。
generic-message = start-line CRLF *message-header CRLF CRLF [ message-body ] start-line = Request-Line / Status-Line
generic-message = start-line CRLF * message-header CRLF CRLF [message-body] start-line = Request-Line / Status-Line
Much of Q4S's messages and header field syntax are identical to HTTP/1.1. However, Q4S is not an extension of HTTP.
Q4Sのメッセージとヘッダーフィールド構文の多くは、HTTP / 1.1と同じです。ただし、Q4SはHTTPの拡張ではありません。
Q4S requests are distinguished by having a Request-Line for a start-line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character.
Q4Sリクエストは、スタートライン用のリクエストラインを持つことで区別されます。 Request-Lineには、メソッド名、Request-URI、およびプロトコルバージョンが1つのスペース（SP）文字で区切られて含まれています。
The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWSP) is allowed in any of the elements.
Request-LineはCRLFで終わります。行末のCRLFシーケンスを除き、CRまたはLFは許可されません。どの要素でも線形空白（LWSP）は許可されていません。
Request-Line = Method SP Request-URI SP Q4S-Version CRLF
Request-Line =メソッドSP Request-URI SP Q4S-Version CRLF
Method: This specification defines seven methods: BEGIN for starting and negotiating quality sessions, READY for synchronization of measurements, PING and BWIDTH for quality measurements purposes, CANCEL for terminating sessions, Q4S-ALERT for reporting quality violations, and Q4S-RECOVERY for reporting quality recovery.
方法：この仕様では7つの方法が定義されています。品質セッションの開始とネゴシエーションのBEGIN、測定の同期のREADY、品質測定の目的のPINGとBWIDTH、セッションの終了のCANCEL、品質違反の報告のQ4S-ALERT、および品質報告のQ4S-RECOVERY回復。
Request-URI: The Request-URI is a Q4S URI [RFC3986] as described in Section 7.4. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in "<>".
Request-URI：セクション7.4で説明されているように、Request-URIはQ4S URI [RFC3986]です。 Request-URIには、エスケープされていないスペースや制御文字を含めることはできません。また、「<>」で囲むことはできません。
Q4S-Version: Both request and response messages include the version of Q4S in use. To be compliant with this specification, applications sending Q4S messages MUST include a Q4S-Version of "Q4S/1.0". The Q4S-Version string is case insensitive, but implementations MUST send uppercase. Unlike HTTP/1.1, Q4S treats the version number as a literal string. In practice, this should make no difference.
Q4S-Version：要求メッセージと応答メッセージの両方に、使用中のQ4Sのバージョンが含まれています。この仕様に準拠するには、Q4Sメッセージを送信するアプリケーションに「Q4S / 1.0」のQ4Sバージョンを含める必要があります。 Q4S-Version文字列は大文字と小文字を区別しませんが、実装は大文字を送信する必要があります。 HTTP / 1.1とは異なり、Q4Sはバージョン番号をリテラル文字列として扱います。実際には、これで違いはありません。
Q4S responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character. No CR or LF is allowed except in the final CRLF sequence.
Q4S応答は、ステータス行を開始行として持つことにより、要求と区別されます。 Status-Lineは、プロトコルバージョンとそれに続く数値のStatus-Codeおよび関連するテキストフレーズで構成され、各要素は単一のSP文字で区切られています。最後のCRLFシーケンスを除いて、CRまたはLFは許可されません。
Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF
Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF
The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase.
Status-Codeは3桁の整数の結果コードであり、要求を理解して満足する試みの結果を示します。 Reason-Phraseは、Status-Codeの短いテキストによる説明を提供することを目的としています。 Status-Codeはオートマトンによる使用を目的としていますが、Reason-Phraseは人間のユーザーを対象としています。クライアントは、Reason-Phraseを調べたり表示したりする必要はありません。
While this specification suggests specific wording for the Reason-Phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request.
この仕様はReason-Phraseの特定の表現を提案していますが、実装は、たとえば、リクエストのAccept-Languageヘッダーフィールドに示されている言語で、他のテキストを選択する場合があります。
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response", any response with a status code between 200 and 299 as a "2xx response", and so on. Q4S/1.0 allows following values for the first digit:
ステータスコードの最初の桁は、応答のクラスを定義します。下2桁には、分類の役割はありません。このため、ステータスコードが100から199のレスポンスは「1xxレスポンス」、ステータスコードが200から299のレスポンスは「2xxレスポンス」と呼ばれます。 Q4S / 1.0では、最初の桁に次の値を使用できます。
1xx: Provisional -- request received, continuing to process the request;
1xx：暫定-要求を受け取り、要求の処理を続行します。
2xx: Success -- the action was successfully received, understood, and accepted;
2xx：成功-アクションは正常に受信され、理解され、受け入れられました。
3xx: Redirection -- further action needs to be taken in order to complete the request;
3xx：リダイレクト-リクエストを完了するには、さらにアクションを実行する必要があります。
4xx: Request Failure -- the request contains bad syntax or cannot be fulfilled at this server;
4xx：リクエストの失敗-リクエストに不正な構文が含まれているか、このサーバーで実行できません。
5xx: Server Error -- the server failed to fulfill an apparently valid request;
5xx：サーバーエラー-サーバーは明らかに有効な要求を実行できませんでした。
6xx: Global Failure -- the request cannot be fulfilled at any server.
6xx：グローバルエラー-リクエストはどのサーバーでも実行できません。
The status codes are the same as described in HTTP [RFC7231]. In the same way as HTTP, Q4S applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class.
ステータスコードは、HTTP [RFC7231]で説明されているものと同じです。 HTTPと同じように、Q4Sアプリケーションは登録されたすべてのステータスコードの意味を理解する必要はありませんが、そのような理解は明らかに望ましいです。ただし、アプリケーションは最初の桁で示されるように、ステータスコードのクラスを理解し、認識されない応答をそのクラスのx00ステータスコードと同等のものとして扱う必要があります。
The Q4S-ALERT, Q4S-RECOVERY, and CANCEL requests do not have to be responded to. However, after receiving a Q4S-ALERT, Q4S-RECOVERY, or CANCEL request, the server SHOULD send a Q4S-ALERT, Q4S-RECOVERY, or CANCEL request to the client.
Q4S-ALERT、Q4S-RECOVERY、およびCANCEL要求に応答する必要はありません。ただし、Q4S-ALERT、Q4S-RECOVERY、またはCANCEL要求を受信した後、サーバーはQ4S-ALERT、Q4S-RECOVERY、またはCANCEL要求をクライアントに送信する必要があります（SHOULD）。
Q4S header fields are identical to HTTP header fields in both syntax and semantics.
Q4Sヘッダーフィールドは、構文とセマンティクスの両方でHTTPヘッダーフィールドと同じです。
Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message that does not match its category (such as a request header field in a response), it MUST be ignored.
一部のヘッダーフィールドは、リクエストまたはレスポンスでのみ意味があります。これらは、それぞれ要求ヘッダーフィールドと応答ヘッダーフィールドと呼ばれます。カテゴリに一致しないメッセージにヘッダーフィールドが表示される場合（応答の要求ヘッダーフィールドなど）、それは無視されなければなりません（MUST）。
These fields may appear in request and response messages.
これらのフィールドは、要求および応答メッセージに表示される場合があります。
Session-Id: the value for this header field is the same sess-id used in SDP (embedded in the SDP "o=" line) and is assigned by the server. The messages without SDP MUST include this header field. If a message has an SDP body, this header field is optional. The method of sess-id allocation is up to the creating tool, but it is suggested that a UTC timestamp be used to ensure uniqueness.
セッションID：このヘッダーフィールドの値は、SDPで使用されるものと同じsess-id（SDP "o ="行に埋め込まれている）であり、サーバーによって割り当てられます。 SDPのないメッセージには、このヘッダーフィールドを含める必要があります。メッセージにSDP本体がある場合、このヘッダーフィールドはオプションです。 sess-idの割り当て方法は作成ツール次第ですが、一意性を確保するためにUTCタイムスタンプを使用することをお勧めします。
Sequence-Number: sequential and cyclic positive integer number assigned to PING and BWIDTH messages and acknowledged in 200 OK responses.
シーケンス番号：PINGおよびBWIDTHメッセージに割り当てられ、200 OK応答で確認応答される連続した循環正整数。
Timestamp: this optional header field contains the system time (with the best possible accuracy). It indicates the time in which the PING request was sent. If this header field is present in PING messages, then the 200 OK response messages MUST include this value.
タイムスタンプ：このオプションのヘッダーフィールドには、システム時刻が含まれます（可能な限り最高の精度で）。 PINGリクエストが送信された時間を示します。このヘッダーフィールドがPINGメッセージに存在する場合、200 OK応答メッセージにはこの値を含める必要があります。
Stage: this is used in the client's READY requests and the server's 200 OK responses during the Negotiation and Continuity phases in order to synchronize the initiation of the measurements. Example: Stage: 0
ステージ：これは、測定の開始を同期するために、ネゴシエーションおよび継続フェーズ中にクライアントのREADYリクエストとサーバーの200 OK応答で使用されます。例：ステージ：0
In addition to HTTP header fields, these are the specific Q4S request header fields:
HTTPヘッダーフィールドに加えて、これらは特定のQ4Sリクエストヘッダーフィールドです。
User-Agent: this header field contains information about the implementation of the user agent. This is for statistical purposes, the tracing of protocol violations, and the automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field MAY contain multiple product tokens and comments identifying the agent and any sub-products that form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
User-Agent：このヘッダーフィールドには、ユーザーエージェントの実装に関する情報が含まれています。これは、統計上の目的、プロトコル違反の追跡、特定のユーザーエージェントの制限を回避するために応答を調整するためのユーザーエージェントの自動認識のためのものです。ユーザーエージェントは、リクエストにこのフィールドを含める必要があります。フィールドには、ユーザーエージェントの重要な部分を形成するエージェントとサブ製品を識別する複数の製品トークンとコメントが含まれる場合があります。慣例により、製品トークンは、アプリケーションを識別するための重要度の順にリストされています。
Signature: this header field contains a digital signature that can be used by the network, Actuator, or policy server to validate the SDP, preventing security attacks. The Signature is an optional header field generated by the server according to the pre-agreed security policies between the Application Content Provider and the ISP. For example, a hash algorithm and encryption method such as SHA256 [RFC6234] and RSA [RFC8017] based on the server certificate could be used. This certificate is supposed to be delivered by a Certification Authority (CA) or policy owner to the server. The signature is applied to the SDP body.
署名：このヘッダーフィールドには、ネットワーク、アクチュエータ、またはポリシーサーバーがSDPを検証してセキュリティ攻撃を防ぐために使用できるデジタル署名が含まれています。署名は、アプリケーションコンテンツプロバイダーとISPの間の事前に合意されたセキュリティポリシーに従ってサーバーによって生成されるオプションのヘッダーフィールドです。たとえば、ハッシュアルゴリズムと、サーバー証明書に基づくSHA256 [RFC6234]やRSA [RFC8017]などの暗号化方法を使用できます。この証明書は、認証局（CA）またはポリシー所有者によってサーバーに配信されることになっています。署名はSDP本体に適用されます。
Signature= RSA ( SHA256 (<sdp>), <certificate> )
If the Signature header field is not present, other validation mechanisms MAY be implemented in order to provide assured quality with security and control.
Signatureヘッダーフィールドが存在しない場合、保証された品質とセキュリティと制御を提供するために、他の検証メカニズムが実装される場合があります。
Measurements: this header field carries the measurements of the quality parameters in PING and BWIDTH requests. The format is:
測定値：このヘッダーフィールドには、PINGおよびBWIDTHリクエストの品質パラメーターの測定値が含まれます。形式は次のとおりです。
Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl="
" "|[0.00 .. 100.00] ", bw=" " "|[0..999999]
Where "l" stands for latency followed by the measured value (in milliseconds) or an empty space, "j" stands for jitter followed by the measured value (in milliseconds) or an empty space, "pl" stands for packet loss followed by the measured value (in percentage with two decimals) or an empty space, and "bw" stands for bandwidth followed by the measured value (in kbps) or an empty space.
「l」はレイテンシの後に測定値（ミリ秒単位）または空きスペースが続くことを表し、「j」はジッタの後に測定値（ミリ秒単位）または空スペースが続くことを表し、「pl」はパケット損失の後に続く測定値（小数点以下2桁のパーセンテージ）または空スペース。「bw」は帯域幅の後に測定値（kbps）または空スペースが続くことを意味します。
Expires: its purpose is to provide a sanity check and allow the server to close inactive sessions. If the client does not send a new request before the expiration time, the server MAY close the session. The value MUST be an integer, and the measurement units are milliseconds.
期限切れ：その目的は、健全性チェックを提供し、サーバーが非アクティブなセッションを閉じることを可能にすることです。クライアントが有効期限の前に新しいリクエストを送信しない場合、サーバーはセッションを閉じてもよい（MAY）。値は整数である必要があり、測定単位はミリ秒です。
In order to keep the session open, the server MUST send a Q4S alert before the session expiration (Expires header field), with the same quality levels and an alert cause of "keep-alive". The purpose of this alert is to avoid TCP sockets, which were opened with READY message, from being closed, specially in NAT scenarios.
セッションを開いたままにしておくために、サーバーは、セッションの有効期限が切れる前に（Expiresヘッダーフィールド）、Q4Sアラートを送信する必要があります。同じ品質レベルと「キープアライブ」のアラート原因があります。このアラートの目的は、特にNATシナリオで、READYメッセージで開かれたTCPソケットが閉じられないようにすることです。
Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted. The interpretation of the body depends on the request method.
この仕様の拡張で定義された新しいリクエストを含むリクエストには、特に明記されていない限り、メッセージ本文を含めることができます。本文の解釈は、リクエストメソッドによって異なります。
For response messages, the request method and the response status code determine the type and interpretation of any message body. All responses MAY include a body.
応答メッセージの場合、要求メソッドと応答ステータスコードによって、メッセージ本文のタイプと解釈が決まります。すべての応答に本文が含まれる場合があります。
The Internet media type of the message body MUST be given by the Content-Type header field.
メッセージ本文のインターネットメディアタイプは、Content-Typeヘッダーフィールドで指定する必要があります。
The body MUST NOT be compressed. This mechanism is valid for other protocols such as HTTP and SIP [RFC3261], but a compression/coding scheme will limit the way the request is parsed to certain logical implementations, thus making the protocol concept more implementation dependent. In addition, the bandwidth calculation may not be valid if compression is used. Therefore, the HTTP Accept-Encoding request header field cannot be used in Q4S with values different from "identity", and if it is present in a request, the server MUST ignore it. In addition, the response header field Content-Encoding is optional, but if present, the unique permitted value is "identity".
ボディを圧縮してはなりません。このメカニズムは、HTTPやSIP [RFC3261]などの他のプロトコルでも有効ですが、圧縮/コーディングスキームにより、要求の解析方法が特定の論理実装に制限されるため、プロトコルの概念は実装依存性が高くなります。また、圧縮が使用されている場合、帯域幅の計算が無効になることがあります。したがって、HTTP Accept-Encodingリクエストヘッダーフィールドは、「identity」とは異なる値を持つQ4Sでは使用できません。リクエストに存在する場合、サーバーはそれを無視する必要があります。また、応答ヘッダーフィールドContent-Encodingはオプションですが、存在する場合、許可される一意の値は「identity」です。
The body length in bytes MUST be provided by the Content-Length header field. The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for Q4S.
バイト単位の本文の長さは、Content-Lengthヘッダーフィールドで指定する必要があります。 HTTP / 1.1の「チャンク」転送エンコーディングは、Q4Sに使用してはなりません（MUST NOT）。
| Note: The chunked encoding modifies the body of a message in | order to transfer it as a series of chunks, each one with its | own size indicator.
|注：チャンクエンコーディングは、|のメッセージの本文を変更します。それを一連のチャンクとして転送するための順序。独自のサイズインジケータ。
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case sensitive.
Methodトークンは、Request-URIで識別されるリソースで実行されるメソッドを示します。このメソッドでは大文字と小文字が区別されます。
Method = "BEGIN" | "READY" | "PING" | "BWIDTH" | "Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" | extension-method
メソッド= "BEGIN" | 「準備完了」| 「PING」| 「BWIDTH」| 「Q4S-ALERT」| 「Q4S-RECOVERY」| 「キャンセル」|拡張メソッド
extension-method = token
extension-method = token
The list of methods allowed by a resource can be specified in an Allow header field [RFC7231]. The return code of the response always notifies the client when a method is currently allowed on a resource, since the set of allowed methods can change dynamically. Any server application SHOULD return the status code 405 (Method Not Allowed) if the method is known, but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the server.
リソースによって許可されるメソッドのリストは、Allowヘッダーフィールド[RFC7231]で指定できます。許可されたメソッドのセットは動的に変更できるため、リソースでメソッドが現在許可されている場合、応答の戻りコードは常にクライアントに通知します。サーバーアプリケーションは、メソッドが既知であるが要求されたリソースに対して許可されていない場合はステータスコード405（メソッドが許可されていない）を返し、メソッドがサーバーによって認識されていないか実装されていない場合は501（実装されていない）を返す必要があります。
The BEGIN method requests information from a resource identified by a Q4S URI. The purpose of this method is to start the quality session.
BEGINメソッドは、Q4S URIで識別されるリソースからの情報を要求します。このメソッドの目的は、高品質のセッションを開始することです。
This method is used only during the Handshake phase to retrieve the SDP containing the sess-id and all quality and operation parameters for the desired application to run.
このメソッドは、ハンドシェイクフェーズでのみ使用され、実行する必要のあるアプリケーションのsess-idとすべての品質および操作パラメーターを含むSDPを取得します。
When a BEGIN message is received by the server, any current quality session MUST be canceled, and a new session should be created.
BEGINメッセージをサーバーが受信すると、現在の品質のセッションをキャンセルする必要があり、新しいセッションを作成する必要があります。
The response to a Q4S BEGIN request is not cacheable.
Q4S BEGIN要求への応答はキャッシュできません。
The READY method is used to synchronize the starting time for the sending of PING and BWIDTH messages over UDP between clients and servers. Including the Stage header field in this method is mandatory.
READYメソッドは、クライアントとサーバー間のUDPを介したPINGおよびBWIDTHメッセージの送信の開始時刻を同期するために使用されます。このメソッドにステージヘッダーフィールドを含めることは必須です。
This message is used only in Negotiation and Continuity phases, and only just before making a measurement. Otherwise (outside of this context), the server MUST ignore this method.
このメッセージは、ネゴシエーションおよび継続フェーズでのみ使用され、測定を行う直前にのみ使用されます。それ以外の場合（このコンテキスト外）、サーバーはこのメソッドを無視する必要があります。
This message is used during the Negotiation and Continuity phases to measure the RTT and jitter of a session. The message MUST be sent only over UDP ports.
このメッセージは、セッションのRTTおよびジッターを測定するために、ネゴシエーションおよび継続フェーズ中に使用されます。メッセージはUDPポート経由でのみ送信する必要があります。
The fundamental difference between the PING and BWIDTH requests is reflected in the different measurements achieved with them. PING is a short message, and it MUST be answered in order to measure RTT and jitter, whereas BWIDTH is a long message and MUST NOT be answered.
PING要求とBWIDTH要求の基本的な違いは、それらを使用して達成されるさまざまな測定に反映されます。 PINGは短いメッセージであり、RTTおよびジッターを測定するために応答する必要がありますが、BWIDTHは長いメッセージであり、応答してはなりません。
PING is a request method that can be originated by either the client or the server. The client MUST also answer the server PING messages, assuming a "server role" for these messages during the measurement process.
PINGは、クライアントまたはサーバーのいずれかから発信できる要求メソッドです。クライアントは、測定プロセス中にこれらのメッセージの「サーバーの役割」を想定して、サーバーのPINGメッセージにも応答する必要があります。
Including the Measurements header field in this method is mandatory, and provides updated measurements values for latency, jitter, and packet loss to the counterpart.
このメソッドにMeasurementsヘッダーフィールドを含めることは必須であり、レイテンシ、ジッター、およびパケット損失の更新された測定値をカウンターパートに提供します。
This message is used only during the Negotiation phase to measure the bandwidth and packet loss of a session. The message MUST be sent only over UDP ports.
このメッセージは、セッションの帯域幅とパケット損失を測定するための交渉フェーズ中にのみ使用されます。メッセージはUDPポート経由でのみ送信する必要があります。
BWIDTH is a request method that can be originated by either the client or the server. Both client and server MUST NOT answer BWIDTH messages.
BWIDTHは、クライアントまたはサーバーのいずれかから発信できる要求メソッドです。クライアントとサーバーの両方がBWIDTHメッセージに応答してはなりません（MUST NOT）。
Including the Measurements header field in this method is mandatory and provides updated measurements values for bandwidth and packet loss to the counterpart.
このメソッドにMeasurementsヘッダーフィールドを含めることは必須であり、帯域幅とパケット損失の更新された測定値を相手に提供します。
This is the request message that Q4S generates when the measurements indicate that quality constraints are being violated. It is used during the Negotiation and Continuity phases.
これは、測定が品質の制約に違反していることを示しているときにQ4Sが生成する要求メッセージです。ネゴシエーションおよび継続フェーズ中に使用されます。
This informative message indicates that the user experience is being degraded and includes the details of the problem (bandwidth, jitter, packet loss measurements). The Q4S-ALERT message does not contain any detail on the actions to be taken, which depend on the agreements between all involved parties.
この情報メッセージは、ユーザーエクスペリエンスが低下していることを示し、問題の詳細（帯域幅、ジッター、パケット損失測定）を含みます。 Q4S-ALERTメッセージには、関係するすべての当事者間の合意に依存する、取るべきアクションの詳細は含まれていません。
Unless there is an error condition, an answer to a Q4S-ALERT request is optional and is formatted as a request Q4S-ALERT message. If there is an error condition, then a response message is sent. The response to a Q4S-ALERT request is not cacheable.
エラー状態がない限り、Q4S-ALERT要求への応答はオプションであり、要求Q4S-ALERTメッセージとしてフォーマットされます。エラー条件がある場合、応答メッセージが送信されます。 Q4S-ALERT要求への応答はキャッシュできません。
This method MUST be initiated by the server in both alerting modes. In the Q4S-aware-network alerting mode, the Q4S-ALERT messages are sent by the server to the client, advising the network to react by itself. In the Reactive alerting mode, alert notifications are triggered by the server stack and sent to the Actuator (see Figure 1, "Reactive Scenario").
このメソッドは、両方のアラートモードでサーバーによって開始される必要があります。 Q4S対応ネットワークアラートモードでは、Q4S-ALERTメッセージがサーバーからクライアントに送信され、ネットワークにそれ自体で反応するようにアドバイスします。リアクティブアラートモードでは、アラート通知はサーバースタックによってトリガーされ、アクチュエーターに送信されます（図1「リアクティブシナリオ」を参照）。
Client----q4s----SERVER STACK--->ACTUATOR-->APP OR POLICY SERVER
The way in which the server stack notifies the Actuator is implementation dependent, and the communication between the Actuator and the network policy server is defined by the protocol and API that the policy server implements.
サーバースタックがアクチュエータに通知する方法は実装に依存し、アクチュエータとネットワークポリシーサーバー間の通信は、ポリシーサーバーが実装するプロトコルとAPIによって定義されます。
This is the request message that Q4S generates when the measurements indicate that quality constraints, which had been violated, have been fulfilled during a period of time ("recovery-pause"). It is used during the Negotiation and Continuity phases.
これは、違反されていた品質の制約が一定期間満たされていることを測定が示したときに「Q4S」が生成する要求メッセージです（「リカバリー・ポーズ」）。ネゴシエーションおよび継続フェーズ中に使用されます。
This informative message indicates that the "qos-level" could be increased gradually until the initial "qos-level" is recovered (the "qos-level" established at the beginning of the session that was decreased during violation of constraints. See Section 7.9). The Q4S-RECOVERY message does not contain any detail on the actions to be taken, which depends on the agreements between all involved parties.
この有益なメッセージは、最初の「qos-level」が回復するまで「qos-level」を徐々に増やすことができることを示しています（セッションの開始時に確立された「qos-level」は、制約違反中に減少しました。7.9節を参照してください） ）。 Q4S-RECOVERYメッセージには、関係するすべての関係者間の合意に応じて、実行するアクションの詳細は含まれていません。
The answer to a Q4S-RECOVERY request is formatted as a request Q4S-RECOVERY message. A Q4S-RECOVERY request MUST NOT be answered with a response message unless there is an error condition. The response to a Q4S-RECOVERY request is not cacheable.
Q4S-RECOVERY要求への応答は、要求Q4S-RECOVERYメッセージとしてフォーマットされます。エラー状態がない限り、Q4S-RECOVERY要求は応答メッセージで応答してはなりません（MUST NOT）。 Q4S-RECOVERY要求への応答はキャッシュできません。
Like the Q4S-ALERT message, the Q4S-RECOVERY method is always initiated by the server in both alerting modes. In the Q4S-aware-network alerting mode, the Q4S-RECOVERY messages are sent by the server to the client, advising the network to react by itself. In the Reactive alerting mode, recovery notifications are triggered by the server stack and sent to the Actuator (see Figure 1, "Reactive Scenario").
Q4S-ALERTメッセージのように、Q4S-RECOVERYメソッドは常に両方のアラートモードでサーバーによって開始されます。 Q4S対応ネットワークアラートモードでは、Q4S-RECOVERYメッセージがサーバーからクライアントに送信され、ネットワーク自体に反応するようにアドバイスします。リアクティブアラートモードでは、回復通知がサーバースタックによってトリガーされ、アクチュエータに送信されます（図1「リアクティブシナリオ」を参照）。
The purpose of the CANCEL message is the release of the Q4S Session-Id and the possible resources assigned to the session. This message could be triggered by the Q4S stack or by the application using the stack (through an implementation-dependent API).
CANCELメッセージの目的は、Q4SセッションIDの解放と、セッションに割り当てられている可能性のあるリソースです。このメッセージは、Q4Sスタック、またはスタックを使用するアプリケーション（実装依存のAPIを使用）によってトリガーされる可能性があります。
In the same way as Q4S-ALERT, CANCEL must not be answered with a response message, but with an answer formatted as a request Q4S-CANCEL message.
Q4S-ALERTと同じように、CANCELは応答メッセージでは応答できませんが、応答は要求Q4S-CANCELメッセージとしてフォーマットされます。
In the Reactive scenario, the server stack MUST react to the Q4S CANCEL messages received from the client by forwarding a cancel notification to the Actuator, in order to release possible assigned resources for the session (at the application or at the policy server). The Actuator MUST answer the cancel notification with a cancel acknowledge towards the server stack, acknowledging the reception.
リアクティブシナリオでは、サーバースタックは、セッションに割り当てられている可能性のあるリソースを（アプリケーションまたはポリシーサーバーで）解放するために、キャンセル通知をアクチュエータに転送することにより、クライアントから受信したQ4S CANCELメッセージに反応する必要があります。アクチュエータは、サーバースタックに対するキャンセル確認でキャンセル通知に応答し、受信を確認する必要があります。
Q4S response codes are used for TCP and UDP. However, in UDP, only the response code 200 is used.
Q4S応答コードは、TCPおよびUDPに使用されます。ただし、UDPでは、応答コード200のみが使用されます。
The receiver of an unknown response code must take a generic action for the received error group (1xx, 2xx, 3xx, 4xx, 5xx, 6xx). In case of an unknown error group, the expected action should be the same as with the 6xx error group.
不明な応答コードの受信者は、受信したエラーグループ（1xx、2xx、3xx、4xx、5xx、6xx）に対して一般的なアクションを実行する必要があります。不明なエラーグループの場合、予期されるアクションは6xxエラーグループと同じです。
This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this request (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of a Q4S-ALERT during the "alert-pause" time.
この応答は、要求がネクストホップサーバーによって受信され、この要求に代わって不特定のアクションが実行されていることを示します（たとえば、データベースが参照されています）。この応答は、他のすべての暫定応答と同様に、「alert-pause」の間、Q4S-ALERTの再送信を停止します。
2xx responses give information about the success of a request.
2xx応答は、要求の成功に関する情報を提供します。
The request has succeeded.
リクエストは成功しました。
3xx responses give information about the user's new location or about alternative services that might be able to satisfy the request.
3xx応答は、ユーザーの新しい場所に関する情報、または要求を満たすことができる代替サービスに関する情報を提供します。
The requesting client SHOULD retry the request at the new address(es) given by the Location header field.
要求側クライアントは、Locationヘッダーフィールドで指定された新しいアドレスで要求を再試行する必要があります（SHOULD）。
4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate header fields or SDP values). However, the same request to a different server might be successful.
4xx応答は、特定のサーバーからの明確な障害応答です。クライアントは変更せずに同じリクエストを再試行すべきではありません（たとえば、適切なヘッダーフィールドやSDP値を追加するなど）。ただし、別のサーバーへの同じ要求は成功する可能性があります。
The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Sequence-Number header field".
不正な構文のため、リクエストを理解できませんでした。 Reason-Phraseは、「Missing Sequence-Number header field」など、構文の問題をより詳細に特定する必要があります（SHOULD）。
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
サーバーには、Request-URIで指定されたドメインにユーザーが存在しないという明確な情報があります。このステータスは、Request-URIのドメインが、リクエストの受信者が処理するドメインのいずれとも一致しない場合にも返されます。
The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI.
Request-Lineで指定されたメソッドは理解されますが、Request-URIで識別されるアドレスには許可されません。
The response MUST include an Allow header field containing a list of valid methods for the indicated address.
応答には、指定されたアドレスの有効なメソッドのリストを含むAllowヘッダーフィールドを含める必要があります。
The resource identified by the request is only able to generate response entities that have content characteristics that are not acceptable according to the Accept header field sent in the request.
リクエストで識別されたリソースは、リクエストで送信されたAcceptヘッダーフィールドに応じて許容できないコンテンツ特性を持つレスポンスエンティティのみを生成できます。
The server could not produce a response within a suitable amount of time, and the client MAY repeat the request without modifications at any later time.
サーバーは適切な時間内に応答を生成できませんでした、そしてクライアントはいつでも変更なしで要求を繰り返すかもしれません。
The server is refusing to process a request because the request entity-body is larger than the one that the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
リクエストのエンティティ本体が、サーバーが処理できるか、または処理できるものより大きいため、サーバーはリクエストの処理を拒否しています。サーバーは接続を閉じて、クライアントがリクエストを続行できないようにすることができます。
The server is refusing to process the request because the Request-URI is longer than the one that the server accepts.
Request-URIがサーバーが受け入れるものよりも長いため、サーバーは要求の処理を拒否しています。
The server is refusing to process the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content.
要求のメッセージ本文が要求されたメソッドのサーバーでサポートされていない形式であるため、サーバーは要求の処理を拒否しています。サーバーは、コンテンツの特定の問題に応じて、Accept、Accept-Encoding、またはAccept-Languageヘッダーフィールドを使用して、受け入れ可能な形式のリストを返す必要があります。
The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server.
Request-URIのURIのスキームがサーバーに認識されていないため、サーバーは要求を処理できません。
5xx responses are failure responses given when a server itself is having trouble.
5xx応答は、サーバー自体に問題が発生したときに出される障害応答です。
The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds.
サーバーで予期しない状態が発生したため、リクエストを実行できませんでした。クライアントは特定のエラー状態を表示してもよく（MAY）、数秒後にリクエストを再試行してもよい（MAY）。
The server does not support the functionality required to fulfill the request. This is the appropriate response when a server does not recognize the request method, and it is not capable of supporting it for any user.
サーバーは、要求を満たすために必要な機能をサポートしていません。これは、サーバーが要求メソッドを認識せず、どのユーザーに対してもサポートできない場合の適切な応答です。
Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported.
サーバーが要求メソッドを認識したときに405（メソッドは許可されていません）が送信されますが、そのメソッドは許可またはサポートされていないことに注意してください。
The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
サーバーの一時的な過負荷またはメンテナンスのため、サーバーは一時的に要求を処理できません。サーバーは、クライアントがRetry-Afterヘッダーフィールドでリクエストを再試行する必要がある時期を示してもよい（MAY）。 Retry-Afterが指定されていない場合、クライアントは500（サーバー内部エラー）応答を受信したかのように動作する必要があります。
A client receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.
503（Service Unavailable）を受信するクライアントは、リクエストを代替サーバーに転送しようとする必要があります（SHOULD）。存在する場合は、Retry-Afterヘッダーフィールドで指定された期間、他の要求をそのサーバーに転送しないでください。
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
サーバーは、503（Service Unavailable）で応答する代わりに、接続を拒否するか、要求をドロップする場合があります。
The server did not receive a timely response from an external server it accessed in attempting to process the request.
サーバーは、リクエストを処理しようとしてアクセスした外部サーバーからタイムリーな応答を受け取りませんでした。
The server does not support, or refuses to support, the Q4S protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message.
サーバーは、リクエストで使用されたQ4Sプロトコルバージョンをサポートしていないか、サポートを拒否します。サーバーは、このエラーメッセージ以外では、クライアントと同じメジャーバージョンを使用して要求を完了できないか、または実行したくないことを示しています。
In the case that the Q4S version is not supported, this error may be sent by the server in the Handshake phase just after receiving the first BEGIN message from client.
Q4Sバージョンがサポートされていない場合、このエラーは、クライアントから最初のBEGINメッセージを受信した直後のハンドシェイクフェーズでサーバーから送信される可能性があります。
The server was unable to process the request because the message length exceeded its capabilities.
メッセージの長さがその機能を超えたため、サーバーは要求を処理できませんでした。
6xx responses indicate that a server has definitive information about a particular policy not satisfied for processing the request.
6xx応答は、サーバーが、要求を処理するために満たされていない特定のポリシーに関する明確な情報を持っていることを示します。
The Session-Id is not valid.
セッションIDが無効です。
The "qos-level" requested is not allowed for the client/server pair.
要求された「QOSレベル」は、クライアント/サーバーのペアでは許可されていません。
The session is not allowed due to some policy (the number of sessions allowed for the server is exceeded, or the time band of the Q4S-ALERT is not allowed for the client/server pair, etc.).
一部のポリシーにより、セッションは許可されません（サーバーで許可されているセッション数を超えているか、Q4S-ALERTの時間帯がクライアント/サーバーペアで許可されていないなど）。
The policy server does not authorize the Q4S-ALERT quality session improvement operation due to an internal or external reason.
内部または外部の理由により、ポリシーサーバーはQ4S-ALERT品質セッション改善操作を承認しません。
This section describes the measurement procedures, the SDP structure of the Q4S messages, the different Q4S protocol phases, and the messages exchanged in them.
このセクションでは、測定手順、Q4SメッセージのSDP構造、さまざまなQ4Sプロトコルフェーズ、およびそれらで交換されるメッセージについて説明します。
All elements of the IP network contribute to quality in terms of latency, jitter, bandwidth, and packet loss. All these elements have their own quality policies in terms of priorities, traffic mode, etc., and each element has its own way to manage the quality. The purpose of a quality connection is to establish end-to-end communication with enough quality for the application to function flawlessly.
IPネットワークのすべての要素は、遅延、ジッター、帯域幅、およびパケット損失の点で品質に貢献します。これらすべての要素には、優先度、トラフィックモードなどの点で独自の品質ポリシーがあり、各要素には、品質を管理する独自の方法があります。高品質の接続の目的は、アプリケーションが問題なく機能するのに十分な品質のエンドツーエンド通信を確立することです。
To monitor quality constraints of the application, four phases are defined and can be seen in Figure 5:
アプリケーションの品質の制約を監視するために、4つのフェーズが定義されており、図5で確認できます。
+---------------------------------------------------------------+
| |
| |
| Handshake ---> Negotiation -+--> Continuity ----> Termination |
| A | (app start) | (app end) |
| | V A V A |
| | violated | violated | |
| | constraints | constraints | |
| | | | |_______| ____| |
| | | | +-------+ | |
| | | | | |
| +------+ +---------------------+ |
| |
+---------------------------------------------------------------+
Figure 5: Session Lifetime Phases
図5：セッションのライフタイムフェーズ
Handshake phase: in which the server is contacted by the client, and in the answer message, the quality constraints for the application are communicated in the embedded SDP.
ハンドシェイクフェーズ：クライアントがサーバーに接続し、応答メッセージで、アプリケーションの品質制約が組み込みSDPで伝達されます。
Negotiation phase: in which the quality of the connection is measured in both directions (latency, jitter, bandwidth, and packet loss), and Q4S messages may be sent in order to alert if the measured quality does not meet the constraints. This phase is iterative until quality constraints are reached, or the session is canceled after a number of measurement cycles with consistent violation of the quality constraints. The number of measurement cycles executed depends on the "qos-level", which is incremented in each cycle until a maximum "qos-level" value is reached. Just after reaching the quality requirements, Q4S provides a simple optional mechanism using HTTP to start the application.
ネゴシエーションフェーズ：接続の品質が両方向で測定され（レイテンシ、ジッター、帯域幅、およびパケット損失）、測定された品質が制約を満たしていない場合に警告するためにQ4Sメッセージが送信されます。このフェーズは、品質の制約に到達するか、品質の制約に一貫して違反する多数の測定サイクルの後でセッションがキャンセルされるまで繰り返されます。実行される測定サイクルの数は、「qos-level」に依存します。これは、最大の「qos-level」値に達するまで、各サイクルで増分されます。品質要件に達した直後、Q4SはHTTPを使用してアプリケーションを起動する簡単なオプションのメカニズムを提供します。
Continuity phase: in which quality is continuously measured. In this phase, the measurements MUST avoid disturbing the application by consuming network resources. If quality constraints are not met, the server stack will notify the Actuator with an alert notification. If later the quality improves, the server stack will notify the Actuator, in this case with a recovery notification. After several alert notifications with no quality improvements, the Q4S stack SHOULD move to the Termination phase.
継続フェーズ：品質が継続的に測定されます。このフェーズでは、測定はネットワークリソースを消費することでアプリケーションに影響を与えないようにする必要があります。品質の制約が満たされない場合、サーバースタックはアクチュエータにアラート通知を通知します。後で品質が向上すると、サーバースタックはアクチュエータに通知し、この場合は回復通知を送信します。品質が改善されていないいくつかのアラート通知の後、Q4Sスタックは終了フェーズに移行する必要があります（SHOULD）。
Termination phase: in which the Q4S session is terminated. The application may be closed also or may not start.
終了フェーズ：Q4Sセッションが終了します。アプリケーションも閉じているか、起動していない可能性があります。
The original goal of SDP was to announce necessary information for the participants and multicast MBONE (Multicast Backbone) applications. Right now, its use has been extended to the announcement and the negotiation of multimedia sessions. The purpose of Q4S is not to establish media stream sessions, but to monitor a quality connection. This connection may be later used to establish any type of session including media sessions; Q4S does not impose any conditions on the type of communication requiring quality parameters.
SDPの当初の目的は、参加者とマルチキャストMBONE（マルチキャストバックボーン）アプリケーションに必要な情報を発表することでした。現在、その使用はマルチメディアセッションの発表と交渉にまで拡大されています。 Q4Sの目的は、メディアストリームセッションを確立することではなく、高品質の接続を監視することです。この接続は、後でメディアセッションを含むあらゆるタイプのセッションを確立するために使用できます。 Q4Sは、高品質のパラメーターを必要とする通信のタイプに条件を課しません。
SDP will be used by Q4S to exchange quality constraints and will therefore always have all the media descriptions ("m=") set to zero.
Q4SはSDPを使用して品質の制約を交換するため、すべてのメディア記述（ "m ="）は常にゼロに設定されます。
The SDP embedded in the messages is the container of the quality parameters. As these may vary depending on the direction of the communication (to and from the client), all quality parameters need to specify the uplink and downlink values: <uplink> / <downlink> (see Section 7.5.3 for an example). When one or both of these values are empty, it MUST be understood as needing no constraint on that parameter and/or that direction.
メッセージに埋め込まれたSDPは、品質パラメーターのコンテナーです。これらは（クライアントとの間の）通信の方向によって異なる可能性があるため、すべての品質パラメーターでアップリンクとダウンリンクの値を指定する必要があります：<uplink> / <downlink>（例については、セクション7.5.3を参照）。これらの値の一方または両方が空の場合、そのパラメーターおよび/またはその方向に制約を必要としないことを理解する必要があります。
The uplink direction MUST be considered as being the communication from the client to the server. The downlink direction MUST be considered as being the communication from the server to the client.
アップリンク方向は、クライアントからサーバーへの通信であると見なされなければなりません（MUST）。ダウンリンク方向は、サーバーからクライアントへの通信であると見なされなければなりません（MUST）。
The SDP information can comprise all or some of the following parameters shown in the example below. This is an example of an SDP message used by Q4S included in the 200 OK response to a Q4S BEGIN request.
SDP情報には、以下の例に示す以下のパラメーターのすべてまたは一部を含めることができます。これは、Q4S BEGINリクエストに対する200 OK応答に含まれるQ4Sによって使用されるSDPメッセージの例です。
v=0
o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33
s=Q4S
i=Q4S parameters
t=0 0
a=qos-level:0/0
a=alerting-mode:Reactive
a=alert-pause:5000
a=public-address:client IP4 198.51.100.51
a=public-address:server IP4 198.51.100.58
a=measurement:procedure default(50/50,75/75,5000,40/80,100/256)
a=latency:40
a=jitter:10/10
a=bandwidth:20/6000
a=packetloss:0.50/0.50
a=flow:app clientListeningPort TCP/10000-20000
a=flow:app clientListeningPort UDP/15000-18000
a=flow:app serverListeningPort TCP/56000
a=flow:app serverListeningPort UDP/56000
a=flow:q4s clientListeningPort UDP/55000
a=flow:q4s clientListeningPort TCP/55001
a=flow:q4s serverListeningPort UDP/56000
a=flow:q4s serverListeningPort TCP/56001
As quality constraints may be changed by applications at any time during the Q4S session lifetime, any Q4S 200 OK response sent by the server to the client in the Negotiation and Continuity phases could also include an SDP body with the new quality requirements stated by the applications from then on. Therefore, in response to any PING request sent by the client to the server, the server could send a Q4S 200 OK with an embedded SDP message that specifies new quality constraints requested by the application.
品質の制約はQ4Sセッションの存続期間中いつでもアプリケーションによって変更される可能性があるため、ネゴシエーションおよび継続フェーズでサーバーからクライアントに送信されるQ4S 200 OK応答には、アプリケーションによって記述された新しい品質要件を持つSDP本体も含まれる可能性がありますあれから。したがって、クライアントからサーバーに送信されたPING要求に応答して、サーバーは、アプリケーションから要求された新しい品質制約を指定する埋め込みSDPメッセージを含むQ4S 200 OKを送信できます。
The "qos-level" attribute contains the QoS level for uplink and downlink. Default values are 0 for both directions. The meaning of each level is out of scope of Q4S, but a higher level SHOULD correspond to a better service quality.
「qos-level」属性には、アップリンクとダウンリンクのQoSレベルが含まれています。デフォルト値は両方向とも0です。各レベルの意味はQ4Sの範囲外ですが、より高いレベルはより良いサービス品質に対応する必要があります（SHOULD）。
Appropriate attribute values: [0..9] "/" [0..9]
適切な属性値：[0..9] "/" [0..9]
The "qos-level" attribute may be changed during the session lifetime, raising or lowering the value as necessary following the network measurements and the application needs.
「qos-level」属性は、セッションの存続期間中に変更でき、ネットワーク測定とアプリケーションのニーズに応じて、必要に応じて値を増減します。
The "alerting-mode" attribute specifies the player in charge of triggering Q4S alerts in the case of constraint violation. There are two possible values:
「alerting-mode」属性は、制約違反の場合にQ4Sアラートをトリガーする担当プレーヤーを指定します。可能な値は2つあります。
Appropriate attribute values: <"Q4S-aware-network"|"Reactive">
Q4S-aware-network: Q4S-ALERT messages are triggered by the server to the client. In this case, the network is supposed to be Q4S aware, and reacts by itself to these alerts.
Q4S-aware-network：Q4S-ALERTメッセージはサーバーによってクライアントにトリガーされます。この場合、ネットワークはQ4S対応であることが想定されており、これらのアラートに単独で反応します。
Reactive: alert notifications are sent by the server stack to the Actuator. In this case, the network is not Q4S aware, and a specific node (Actuator) is in charge of triggering tuning mechanisms, either on the network or in the application.
反応性：アラート通知はサーバースタックによってアクチュエータに送信されます。この場合、ネットワークはQ4S対応ではなく、特定のノード（アクチュエータ）が、ネットワーク上またはアプリケーション内の調整メカニズムのトリガーを担当します。
The "alerting-mode" attribute is optional, and if not present, Reactive alerting mode is assumed.
「alerting-mode」属性はオプションであり、存在しない場合、リアクティブアラートモードが想定されます。
In the Q4S-aware-network scenario, the "alert-pause" attribute specifies the amount of time (in milliseconds) the server waits between consecutive Q4S-ALERT messages sent to the client. In the Reactive scenario, the "alert-pause" attribute specifies the amount of time (in milliseconds) the server stack waits between consecutive alert notifications sent to the Actuator. Measurements are not stopped in Negotiation or Continuity phases during this period of time, but no Q4S-ALERT messages or alert notifications are fired, even with violated quality constraints, allowing for either network reconfigurations or application adjustments.
Q4S対応ネットワークのシナリオでは、「alert-pause」属性は、クライアントに送信される連続するQ4S-ALERTメッセージの間にサーバーが待機する時間（ミリ秒単位）を指定します。 Reactiveシナリオでは、「alert-pause」属性は、アクチュエータに送信される連続したアラート通知の間にサーバースタックが待機する時間（ミリ秒単位）を指定します。この期間中、ネゴシエーションまたは継続フェーズで測定は停止されませんが、品質の制約に違反していても、Q4S-ALERTメッセージやアラート通知は発行されず、ネットワークの再構成やアプリケーションの調整が可能になります。
Appropriate attribute values: [0..60000]
適切な属性値：[0..60000]
In the Q4S-aware-network scenario, the "recovery-pause" attribute specifies the amount of time (in milliseconds) the server waits for initiating the "qos-level" recovery process. Once the recovery process has started, the "recovery-pause" attribute also states the amount of time (in milliseconds) between consecutive Q4S-RECOVERY messages sent by the server to the client (in the Q4S-aware-network scenario) or between recovery notifications sent by the server stack to the Actuator (in the Reactive scenario).
Q4S対応ネットワークのシナリオでは、「recovery-pause」属性は、サーバーが「qosレベル」のリカバリープロセスの開始を待機する時間（ミリ秒単位）を指定します。回復プロセスが開始されると、「recovery-pause」属性は、サーバーからクライアントに送信された連続するQ4S-RECOVERYメッセージの間（Q4S対応ネットワークシナリオの場合）または回復の間の時間（ミリ秒単位）も示しますサーバースタックからアクチュエータに送信される通知（リアクティブシナリオの場合）。
Appropriate attribute values: [0..60000]
適切な属性値：[0..60000]
This attribute contains the public IP address of the client and the server. The server fills these attributes with its own public IP address and the public IP address of the first message received from the client in the Handshake phase.
この属性には、クライアントとサーバーのパブリックIPアドレスが含まれています。サーバーは、これらの属性に独自のパブリックIPアドレスと、ハンドシェイクフェーズでクライアントから受信した最初のメッセージのパブリックIPアドレスを入力します。
The purpose of these attributes is to make available the addressing information to the network policy server or other external entities in charge of processing Q4S-ALERT messages.
これらの属性の目的は、Q4S-ALERTメッセージの処理を担当するネットワークポリシーサーバーまたは他の外部エンティティがアドレス情報を利用できるようにすることです。
Appropriate attribute values: <"client"|"server"> <"IP4"|"IP6">
<value of IP address>
The maximum latency (considered equal for uplink and downlink) tolerance is specified in the "latency" attribute, expressed in milliseconds. In the Q4S-aware-network scenario, if the latency constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, if the latency constraints are not met, an alert notification will be sent to the Actuator. If the "latency" attribute is not present or has a 0 value, no latency constraints need to be met, and no measurements MAY be taken.
最大待ち時間（アップリンクとダウンリンクで等しいと見なされます）の許容範囲は、ミリ秒単位で表される「待ち時間」属性で指定されます。 Q4S対応ネットワークシナリオでは、レイテンシの制約が満たされない場合、Q4S-ALERTメソッドがクライアントに送信されます。リアクティブシナリオでは、レイテンシの制約が満たされない場合、アラート通知がアクチュエータに送信されます。 「レイテンシ」属性が存在しないか、値が0の場合、レイテンシの制約を満たす必要はなく、測定を行うことはできません。
Appropriate attribute values: [0..9999]
適切な属性値：[0..9999]
The maximum uplink and downlink jitter tolerance is specified in the "jitter" attribute, expressed in milliseconds. In the Q4S-aware-network scenario, if the jitter constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, if the latency constraints are not met, an alert notification will be sent to the Actuator. If the "jitter" attribute is not present or has a 0 value, no jitter constraints need to be met, and no measurements MAY be taken.
アップリンクとダウンリンクの最大ジッター許容値は、ミリ秒で表される「ジッター」属性で指定されます。 Q4S対応ネットワークシナリオでは、ジッター制約が満たされない場合、Q4S-ALERTメソッドがクライアントに送信されます。リアクティブシナリオでは、レイテンシの制約が満たされない場合、アラート通知がアクチュエータに送信されます。 「ジッター」属性が存在しないか、値が0の場合、ジッター制約を満たす必要はなく、測定は行われません。
Appropriate attribute values: [0..9999] "/" [0..9999]
適切な属性値：[0..9999] "/" [0..9999]
The minimum uplink and downlink bandwidth is specified in the "bandwidth" attribute, expressed in kbps. In the Q4S-aware-network scenario, if the bandwidth constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, an alert notification will be sent to the Actuator. If the "bandwidth" attribute is not present or has a 0 value, no bandwidth constraints need to be met, and no measurements MAY be taken.
最小アップリンクおよびダウンリンク帯域幅は、kbpsで表される「帯域幅」属性で指定されます。 Q4S対応ネットワークのシナリオでは、帯域幅の制約が満たされない場合、Q4S-ALERTメソッドがクライアントに送信されます。リアクティブシナリオでは、アラート通知がアクチュエータに送信されます。 「帯域幅」属性が存在しないか、値が0の場合、帯域幅の制約を満たす必要はなく、測定を行うことはできません。
Appropriate attribute values: [0..99999] "/" [0..99999]
適切な属性値：[0..99999] "/" [0..99999]
The maximum uplink and downlink packet loss tolerance is specified in the "packetloss" attribute expressed in percentage (two decimal accuracy). In the Q4S-aware-network scenario, if the packetloss constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, an alert notification will be sent to the Actuator. If the "packetloss" attribute is not present or has a 0 value, no packet loss constraints need to be met, and no measurements MAY be taken.
アップリンクとダウンリンクの最大パケット損失許容度は、「packetloss」属性で指定されます。 Q4S対応ネットワークシナリオでは、パケットロスの制約が満たされない場合、Q4S-ALERTメソッドがクライアントに送信されます。リアクティブシナリオでは、アラート通知がアクチュエータに送信されます。 「packetloss」属性が存在しないか、値が0の場合、パケット損失の制約を満たす必要はなく、測定は行われない場合があります。
Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00]
適切な属性値：[0.00 ..100.00] "/"[0.00 ..100.00]
These attributes specify the flows (protocol, destination IP/ports) of data over TCP and UDP ports to be used in uplink and downlink communications.
これらの属性は、アップリンクおよびダウンリンク通信で使用されるTCPおよびUDPポートを介したデータのフロー（プロトコル、宛先IP /ポート）を指定します。
Several "flow" attributes can be defined. These flows identify the listening port (client or server), the protocol (TCP [RFC0793] or UDP [RFC0768]) with the range of ports that are going to be used by the application and, of course, by the Q4S protocol (for quality measurements). All defined flows ("app" and "q4s") will be considered within the same quality profile, which is determined by the "qos-level" attribute in each direction. This allows us to assume that measurements on "q4s" flows are the same as experienced by the application, which is using "app" flows.
いくつかの「フロー」属性を定義できます。これらのフローは、アプリケーションによって、そしてもちろん、Q4Sプロトコルによって使用される予定のポートの範囲で、リスニングポート（クライアントまたはサーバー）、プロトコル（TCP [RFC0793]またはUDP [RFC0768]）を識別します（品質測定）。定義されたすべてのフロー（「アプリ」と「q4s」）は、各方向の「qos-level」属性によって決定される同じ品質プロファイル内であると見なされます。これにより、「q4s」フローの測定値は、「app」フローを使用しているアプリケーションが経験するものと同じであると想定できます。
During Negotiation and Continuity phases, the specified Q4S ports in the "flow:q4s" attributes of SDP will be used for Q4S messages.
ネゴシエーションと継続性フェーズでは、SDPの「flow：q4s」属性で指定されたQ4SポートがQ4Sメッセージに使用されます。
The Q4S flows comprise two UDP flows and two TCP flows (one uplink and one downlink for each one), whereas application traffic MAY consist of many flows, depending on its nature. The Handshake phase takes place through the Q4S Contact URI, using the standard Q4S TCP port. However, the Negotiation and Continuity phases will take place on the Q4S ports (UDP and TCP) specified in the SDP.
Q4Sフローは2つのUDPフローと2つのTCPフロー（それぞれに1つのアップリンクと1つのダウンリンク）で構成されますが、アプリケーショントラフィックはその性質に応じて多くのフローで構成される場合があります。ハンドシェイクフェーズは、標準のQ4S TCPポートを使用して、Q4S連絡先URIを通じて行われます。ただし、ネゴシエーションおよび継続フェーズは、SDPで指定されたQ4Sポート（UDPおよびTCP）で行われます。
The "clientListeningPort" is a port on which the client listens for server requests and MUST be used as the origin port of client responses. The "serverListeningPort" is a port on which the server is listening for incoming messages from the client. The origin port of server responses may be different than the "serverListeningPort" value.
「clientListeningPort」は、クライアントがサーバー要求をリスンするポートであり、クライアント応答の起点ポートとして使用する必要があります。 「serverListeningPort」は、サーバーがクライアントからの着信メッセージをリスニングするポートです。サーバー応答の元のポートは、「serverListeningPort」の値とは異なる場合があります。
If "clientListeningPort" is zero ("a=flow:q4s clientListeningPort TCP/0"), the client MAY choose one randomly per OS standard rules. Client ports inside the SDP must always be matched against actual received port values on the server side in order to deal with NAT/ NAPT devices. If a zero value or incorrect value is present, the server must set the value to the received origin port in the next message with SDP (200 OK, ALERT, and CANCEL messages).
「clientListeningPort」がゼロの場合（「a = flow：q4s clientListeningPort TCP / 0」）、クライアントはOS標準ルールごとにランダムに1つを選択できます（MAY）。 NAT / NAPTデバイスを処理するには、SDP内のクライアントポートを、サーバー側で実際に受信したポート値と常に一致させる必要があります。ゼロ値または誤った値が存在する場合、サーバーは、SDPを含む次のメッセージ（200 OK、ALERT、およびCANCELメッセージ）で受信した起点ポートに値を設定する必要があります。
Attribute values:
<"q4s"|"app"> <"serverListeningPort"|"clientListeningPort">
<"UDP"|"TCP"> <0..65535> [ "-" [0..65535]]
These attributes contain the measurement procedure and the results of the quality measurements.
これらの属性には、測定手順と品質測定の結果が含まれています。
Measurement parameters are included using the session attribute "measurement". The first measurement parameter is the procedure. Q4S provides a "default" procedure for measurements, but others like RTP/RTCP might be used and defined later. This document will only define and explain the "default" procedure.
測定パラメータは、セッション属性「測定」を使用して含まれます。最初の測定パラメータは手順です。 Q4Sは測定の「デフォルト」手順を提供しますが、RTP / RTCPなどの他のものを使用して後で定義する場合があります。このドキュメントでは、「デフォルト」の手順のみを定義して説明します。
In the initial client request, a set of measurement procedures can be sent to the server for negotiation. One measurement procedure line MUST be included in the SDP message for each proposed method. The server MUST answer with only one line with the chosen procedure.
最初のクライアント要求では、一連の測定手順をネゴシエーションのためにサーバーに送信できます。提案された方法ごとに、1つの測定手順行をSDPメッセージに含める必要があります。サーバーは、選択したプロシージャを1行だけで応答する必要があります。
For each procedure, a set of values of parameters separated by "," can be included in the same attribute line. The amount and type of parameters depends on the procedure type.
手順ごとに、「、」で区切られたパラメーターの値のセットを同じ属性行に含めることができます。パラメータの数とタイプは、プロシージャのタイプによって異なります。
In the following example, the "default" procedure type is chosen:
次の例では、「デフォルト」のプロシージャタイプが選択されています。
a=measurement:procedure default(50/50,75/75,5000,40/80,100/256)
In the "default" procedure, the meaning of these parameters is the following:
「デフォルト」の手順では、これらのパラメータの意味は次のとおりです。
* The first parameter is the interval of time (in milliseconds) between PING requests during the Negotiation phase. Uplink and downlink values from the client's point of view are separated by "/". This allows different responsiveness values depending on the control resources used in each direction.
* 最初のパラメーターは、ネゴシエーションフェーズ中のPING要求間の時間間隔（ミリ秒単位）です。クライアントから見たアップリンクとダウンリンクの値は、「/」で区切られます。これにより、各方向で使用される制御リソースに応じて、異なる応答性の値が可能になります。
* The second parameter is the time interval (in milliseconds) between PING requests during the Continuity phase. Uplink and downlink values are separated by "/". This allows two different responsiveness values depending on the control resources used in each direction.
* 2番目のパラメーターは、継続フェーズ中のPING要求間の時間間隔（ミリ秒単位）です。アップリンクとダウンリンクの値は「/」で区切られます。これにより、各方向で使用される制御リソースに応じて、2つの異なる応答値が可能になります。
* The third parameter is the time interval to be used to measure bandwidth during the Negotiation phase.
* 3番目のパラメーターは、ネゴシエーションフェーズ中に帯域幅を測定するために使用される時間間隔です。
* The fourth parameter indicates the window size for jitter and latency calculations. Uplink and downlink values are separated by "/".
* 4番目のパラメーターは、ジッターと待ち時間の計算のウィンドウサイズを示します。アップリンクとダウンリンクの値は「/」で区切られます。
* The fifth parameter indicates the window size for packet loss calculations. Uplink and downlink values are separated by "/".
* 5番目のパラメーターは、パケット損失計算のウィンドウサイズを示します。アップリンクとダウンリンクの値は「/」で区切られます。
There are four more "measurement" attributes:
さらに4つの「測定」属性があります。
a=measurement:latency 45
a=measurement:jitter 3/12
a=measurement:bandwidth 200/9800
a=measurement:packetloss 0.00/1.00
The "measurement:latency", "measurement:jitter", "measurement:bandwidth", and "measurement:packetloss" attributes contain the values measured for each of these quality parameters in uplink and downlink directions. Notice that latency is considered equal for uplink and downlink directions. Quality parameter values in these "measurement" attributes provide a snapshot of the quality reached and MUST only be included in Q4S-ALERT messages in the SDP body such that they can be protected from malicious attacks as these alerts include a signature of the SDP body in the header. The rest of the messages will include the measured values in the Measurements header field.
「measurement：latency」、「measurement：jitter」、「measurement：bandwidth」、および「measurement：packetloss」属性には、これらの品質パラメーターのそれぞれについて、アップリンクおよびダウンリンク方向で測定された値が含まれます。待ち時間は、アップリンク方向とダウンリンク方向で等しいと見なされることに注意してください。これらの「測定」属性の品質パラメーター値は、到達した品質のスナップショットを提供し、これらのアラートにはSDP本体のシグネチャが含まれているため、悪意のある攻撃から保護できるように、SDP本体のQ4S-ALERTメッセージにのみ含める必要がありますヘッダー。残りのメッセージには、Measurementsヘッダーフィールドの測定値が含まれます。
In the case of the "default" procedure, the valid values are as follows:
「デフォルト」の手順の場合、有効な値は次のとおりです。
a=measurement:procedure default,[0..999]"/" [0..999] "," [0..999]
"/" [0..999] "," [0..9999] "," [0..999]/[0..999] ","
[0..999]/[0..999]
The adaptation of measurement traffic to approximate the actual data streams' characteristics is convenient to accurately estimate the expected QoS for applications. Particularly, packet size can have a remarkable effect on bandwidth estimations. Moreover, this can produce problems depending on the MTU of the end hosts and links along the path.
実際のデータストリームの特性を近似するための測定トラフィックの適応は、アプリケーションに期待されるQoSを正確に推定するのに便利です。特に、パケットサイズは帯域幅の推定に大きな影響を与える可能性があります。さらに、これは、パスに沿ったエンドホストとリンクのMTUによっては問題を引き起こす可能性があります。
Therefore, the maximum content length MAY be set in an attribute denoted as "max-content-length". Its value MUST be given in bytes and MUST NOT include application, transport, network, or link layer headers, i.e., size of the content length at the application layer. If not set, the value MUST be 1000 bytes.
したがって、最大コンテンツ長は、「max-content-length」として示される属性に設定される場合があります。その値はバイト単位で指定する必要があり、アプリケーション、トランスポート、ネットワーク、またはリンク層のヘッダー、つまりアプリケーション層でのコンテンツの長さのサイズを含めることはできません。設定しない場合、値は1000バイトにする必要があります。
Furthermore, this attribute MAY be used to communicate MTU limits in endpoints, hence reducing possible bias as a result of network-layer fragmentation.
さらに、この属性は、エンドポイントでMTU制限を伝達するために使用できるため、ネットワーク層の断片化の結果として生じる可能性のあるバイアスを低減できます。
For instance:
例えば：
a=max-content-length:1300
a = max-content-length：1300
This section describes the way quality parameters are measured as defined by the "default" procedure. Measurements MUST be taken for any quality parameter with constraints, that is, specified in the SDP attributes with non-zero values. For absent attributes, measurements MAY be omitted.
このセクションでは、「デフォルト」の手順で定義された品質パラメーターの測定方法について説明します。測定は、制約のある、つまりゼロ以外の値を持つSDP属性で指定された品質パラメーターに対して行う必要があります。属性がない場合、測定値は省略される場合があります。
Latency measurements will be performed if the "latency" attribute and/or the "a=measurement:latency" attribute are present and have non-zero values.
「レイテンシ」属性または「a = measurement：latency」属性が存在し、ゼロ以外の値がある場合、レイテンシ測定が実行されます。
Q4S defines a PING method in order to exchange packets between the client and the server. Based on this PING exchange, the client and the server are able to calculate the round-trip time (RTT). The RTT is the sum of downlink latency (normally named "reverse latency") and uplink latency (normally named "forward latency").
Q4Sは、クライアントとサーバー間でパケットを交換するためのPINGメソッドを定義しています。このPING交換に基づいて、クライアントとサーバーは往復時間（RTT）を計算できます。 RTTは、ダウンリンクレイテンシ（通常は「リバースレイテンシ」と呼ばれる）とアップリンクレイテンシ（通常は「フォワードレイテンシ」と呼ばれる）の合計です。
At least 255 samples of RTT MUST be taken by the client and server. As the forward and reverse latencies are impossible to measure, the client and server will assume that both latencies are identical (symmetric network assumption). The latency will therefore be calculated as the statistical median value of all the RTT samples divided by 2.
RTTの少なくとも255のサンプルをクライアントとサーバーで取得する必要があります。フォワードレイテンシとリバースレイテンシは測定できないため、クライアントとサーバーは両方のレイテンシが同一であると想定します（対称ネットワークの想定）。したがって、待ち時間は、すべてのRTTサンプルの統計中央値を2で割ったものとして計算されます。
Jitter measurements will be performed if the "jitter" attribute and/ or the "a=measurement:jitter" attribute are present and have non-zero values.
「ジッター」属性または「a = measurement：jitter」属性が存在し、ゼロ以外の値がある場合、ジッター測定が実行されます。
The jitter can be calculated independently by the client and by the server. The downlink jitter is calculated by the client taking into account the time interval between PING requests as defined by the "measurement:procedure" attribute in the first or second parameter depending on the Q4S protocol phase. The client and the server MUST send these PING requests at the specified intervals. The client measures the downlink jitter, whereas the server measures the uplink jitter. Note that PING responses are not taken into account when calculating jitter values.
ジッタは、クライアントとサーバーが個別に計算できます。ダウンリンクジッタは、Q4Sプロトコルフェーズに応じて、最初のパラメータまたは2番目のパラメータの「measurement：procedure」属性で定義されたPING要求間の時間間隔を考慮して、クライアントによって計算されます。クライアントとサーバーは、指定された間隔でこれらのPING要求を送信する必要があります。クライアントはダウンリンクジッターを測定し、サーバーはアップリンクジッターを測定します。ジッタ値を計算する場合、PING応答は考慮されないことに注意してください。
Every time a PING request is received by an endpoint (either server or client), the corresponding jitter value is updated with the statistical jitter value, which is the arithmetic mean of the absolute values of elapsed times calculated on the first 255 packets received.
エンドポイント（サーバーまたはクライアントのいずれか）がPING要求を受信するたびに、対応するジッター値は、受信した最初の255パケットで計算された経過時間の絶対値の算術平均である統計ジッター値で更新されます。
Each endpoint sends a PING periodically with a fixed interval, and each value of "elapsed time" (ET) should be very close to this interval. If a PING message is lost, the ET value is doubled. Identifying lost PING messages, however, is not an issue because all PING messages are labeled with a Sequence-Number header field. Therefore, the receiver can discard this ET value.
各エンドポイントは固定間隔で定期的にPINGを送信し、「経過時間」（ET）の各値はこの間隔に非常に近い必要があります。 PINGメッセージが失われた場合、ET値は2倍になります。ただし、失われたPINGメッセージの識別は、すべてのPINGメッセージにSequence-Numberヘッダーフィールドのラベルが付いているため、問題にはなりません。したがって、レシーバーはこのET値を破棄できます。
In order to have the first jitter sample, the receiver MUST wait until it receives 3 PING requests, because each ET is the time between two PINGs, and a jitter measurement needs at least two ET.
各ETは2つのPING間の時間であり、ジッター測定には少なくとも2つのETが必要であるため、最初のジッターサンプルを取得するには、レシーバーは3つのPING要求を受信するまで待機する必要があります。
The client measures the values of RTT and downlink jitter, and the server measures RTT and uplink jitter, but all measurements are shared with the counterpart by means of the Measurements header field of the PING message.
クライアントはRTTとダウンリンクジッタの値を測定し、サーバーはRTTとアップリンクジッタを測定しますが、すべての測定値は、PINGメッセージのMeasurementsヘッダーフィールドを使用して相手と共有されます。
Bandwidth measurements will be performed if the "bandwidth" attribute and/or the "a=measurement:bandwidth" attribute is present and has non-zero values.
「帯域幅」属性または「a = measurement：bandwidth」属性が存在し、ゼロ以外の値がある場合、帯域幅測定が実行されます。
In order to measure the available bandwidth, both the client and the server MUST start sending BWIDTH messages simultaneously using the UDP control ports exchanged during the Handshake phase in the SDP message at the needed rate to verify the availability of the bandwidth constraint in each direction. The messages are sent during the period of time defined in the third parameter of the SDP "measurement:procedure default" attribute in milliseconds.
利用可能な帯域幅を測定するために、クライアントとサーバーの両方が、必要なレートでSDPメッセージのハンドシェイクフェーズ中に交換されたUDP制御ポートを使用してBWIDTHメッセージの送信を同時に開始し、各方向の帯域幅制約の可用性を確認する必要があります。メッセージは、SDPの「measurement：procedure default」属性の3番目のパラメーターで定義された期間（ミリ秒単位）中に送信されます。
a=measurement:procedure default(50/50,75/75,5000,256/256,256/256)
+------------------------------------------------+
| Rate |
| A |
| | |
|downlink rate-|-------------------+ <-- traffic |
| | | sent by |
| | | server |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| uplink rate-|-------------------+ <-- traffic |
| | | sent by |
| | | client |
| | | |
| | | |
| |---|---|---|---|---|----> time |
| 0 1 2 3 4 5 (sec.) |
| |
+------------------------------------------------+
Figure 6: Bandwidth and Packet Loss Measurements
図6：帯域幅とパケット損失の測定
The goal of these measurements is not to identify the available bandwidth of the communication path, but to determine if the required bandwidth is available, meeting the application's constraints. Therefore, the requested bandwidth MUST be measured sending only the highest bitrate required by the bandwidth attribute. This is illustrated in Figure 6.
これらの測定の目的は、通信パスの利用可能な帯域幅を特定することではなく、アプリケーションの制約を満たす必要な帯域幅が利用可能かどうかを判断することです。したがって、要求された帯域幅は、帯域幅属性に必要な最高のビットレートのみを送信して測定する必要があります。これを図6に示します。
ALERTS are not expected during bandwidth measurement, but only at the end of the measurement time.
ALERTSは、帯域幅測定中には予期されませんが、測定時間の終わりにのみ予期されます。
When measuring bandwidth, all BWIDTH requests sent MUST be 1 kilobyte in length (UDP payload length by default), they MUST include a Sequence-Number header field with a sequential number starting at 0, and their content MUST consist of randomly generated values to minimize the effect of compression elements along the path. The Sequence-Number MUST be incremented by 1 with each BWIDTH packet sent. If any measurement stage needs to be repeated, the sequence number MUST start at zero again. BWIDTH requests MUST NOT be answered. Examples:
帯域幅を測定する場合、送信されるすべてのBWIDTH要求の長さは1キロバイト（デフォルトではUDPペイロード長）である必要があり、0から始まる連続番号を持つSequence-Numberヘッダーフィールドを含める必要があり、最小化するためにコンテンツはランダムに生成された値で構成する必要がありますパスに沿った圧縮要素の効果。シーケンス番号は、BWIDTHパケットが送信されるたびに1ずつ増加する必要があります。測定段階を繰り返す必要がある場合は、シーケンス番号をゼロから再び開始する必要があります。 BWIDTHリクエストには応答しないでください。例：
Client message:
=========================
BWIDTH q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765
Sequence-Number: 0
Content-Type: text
Content-Length: XXXX
Measurements: l=22, j=10, pl=0.00, bw=3000
VkZaU1FrNVZNVlZSV0doT1ZrZ (to complete up to "max-content-
length" bytes UDP payload length)
=========================
The client MUST send BWIDTH packets to the server to allow the server to measure the uplink bandwidth. The server MUST send BWIDTH packets to the client to allow the client to measure the downlink bandwidth.
クライアントがBWIDTHパケットをサーバーに送信して、サーバーがアップリンク帯域幅を測定できるようにする必要があります。サーバーはクライアントにBWIDTHパケットを送信して、クライアントがダウンリンク帯域幅を測定できるようにする必要があります。
Server message:
=========================
BWIDTH q4s://www.example.com Q4S/1.0
Session-Id: 53655765
Sequence-Number: 0
Content-Type: text
Content-Length: XXXX
Measurements: l=22, j=7, pl=0.00, bw=200
ZY0VaT1ZURlZVVmhyUFE9PQ (to complete up to max-content-
length UDP payload length)
=========================
Packet loss and bandwidth are measured simultaneously using the BWIDTH packets sent by both the client and the server. Because the BWIDTH packets contain a Sequence-Number header field incremented sequentially with each sent packet, lost packets can be easily identified. The lost packets MUST be counted during the measurement time.
パケット損失と帯域幅は、クライアントとサーバーの両方から送信されたBWIDTHパケットを使用して同時に測定されます。 BWIDTHパケットには、送信されるパケットごとに順次増分されるシーケンス番号ヘッダーフィールドが含まれているため、失われたパケットは簡単に識別できます。失われたパケットは、測定時間中にカウントされる必要があります。
The first phase consists of a Q4S BEGIN method issued from the client to the server as shown in Figure 7.
図7に示すように、最初のフェーズは、クライアントからサーバーに発行されるQ4S BEGINメソッドで構成されます。
The first Q4S message MUST have a special URI [RFC3986], which forces the use of the Q4S protocol if it is implemented in a standard web browser.
最初のQ4Sメッセージには特別なURI [RFC3986]が必要です。これは、標準のWebブラウザーに実装されている場合、Q4Sプロトコルの使用を強制します。
This URI, named "Contact URI", is used to request the start of a session. Its scheme MUST be:
「URI」という名前のこのURIは、セッションの開始を要求するために使用されます。そのスキームは：
"q4s:" "//" host [":" port] [path["?" query]
Optionally, the client can send the desired quality parameters enclosed in the body of the message as an SDP document. The server MAY take them into account when building the answer message with the final values in the SDP body, following a request/response schema [RFC3264].
必要に応じて、クライアントは、メッセージの本文に囲まれた必要な品質パラメータをSDPドキュメントとして送信できます。サーバーは、リクエスト/レスポンススキーマ[RFC3264]に従って、SDPボディの最終値を含む応答メッセージを作成するときにそれらを考慮に入れる場合があります。
If the request is accepted, the server MUST answer it with a Q4S 200 OK message, which MUST contain an SDP body [RFC4566] with the assigned sess-id (embedded in the SDP "o=" line), the IP addresses to be used, the flow ports to be used, the measurement procedure to be followed, and information about the required quality constraints. Additionally, the "alerting-mode" and "alert-pause" time attributes may be included. Q4S responses should use the protocol designator "Q4S/1.0".
リクエストが受け入れられた場合、サーバーは、Q4S 200 OKメッセージで応答する必要があります。このメッセージには、SDP本体[RFC4566]と割り当てられたsess-id（SDP "o ="行に埋め込まれている）、IPアドレスが含まれている必要があります。使用、使用するフローポート、従うべき測定手順、および必要な品質制約に関する情報。さらに、「alerting-mode」および「alert-pause」時間属性が含まれる場合があります。 Q4S応答では、プロトコル指定子「Q4S / 1.0」を使用する必要があります。
After these two messages are exchanged, the first phase is completed. The quality parameter thresholds have been sent to the client. The next step is to measure the actual quality of the communication path between the client and the server and alert if the Service Level Agreement (SLA) is being violated.
これら2つのメッセージが交換された後、最初のフェーズが完了します。品質パラメータのしきい値がクライアントに送信されました。次のステップは、クライアントとサーバー間の通信パスの実際の品質を測定し、サービスレベルアグリーメント（SLA）に違反しているかどうかを警告することです。
+------------------------------------------------+
| |
| Client Server |
| |
| ------- Q4S BEGIN ------------> |
| |
| <------ Q4S 200 OK ------------ |
| |
| |
+------------------------------------------------+
Figure 7: Handshake Phase
図7：ハンドシェイクフェーズ
The following is an example of a client request and a server answer:
以下は、クライアント要求とサーバー応答の例です。
Client Request:
=========================
BEGIN q4s://www.example.com Q4S/1.0
Content-Type: application/sdp
User-Agent: q4s-ua-experimental-1.0
Content-Length: 142
(SDP not shown)
=========================
Server Answer:
=========================
Q4S/1.0 200 OK
Date: Mon, 10 Jun 2010 10:00:01 GMT
Content-Type: application/sdp
Expires: 3000
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131
(SDP not shown)
=========================
The header fields used are explained in Section 4.3.
使用されるヘッダーフィールドについては、セクション4.3で説明します。
The Negotiation phase is in charge of measuring the quality parameters and verifying that the communication paths meet the required quality constraints in both directions as specified in the SDP body.
ネゴシエーションフェーズは、品質パラメータの測定と、通信パスがSDP本体で指定された双方向の必要な品質制約を満たすことを確認することを担当します。
The measured parameters will be compared with the quality constraints specified in the SDP body. If the quality session is compliant with all the quality constraints, the application can start.
測定されたパラメーターは、SDP本体で指定された品質制約と比較されます。品質セッションがすべての品質制約に準拠している場合、アプリケーションを開始できます。
If the quality constraints are not met, a higher quality service level will be demanded. Depending on the scenario, this quality upgrade will be managed as follows:
品質の制約が満たされない場合、より高い品質のサービスレベルが要求されます。シナリオに応じて、この品質アップグレードは次のように管理されます。
In the Q4S-aware-network scenario: a Q4S-ALERT method will be triggered by the server to the client, and the client will answer with the same Q4S-ALERT method. After receiving the same Q4S-ALERT from the counterpart, no other alerts will be triggered by the server during the "alert-pause" period of time in order to allow the network to react, but measurements will continue to be taken to achieve early detection of improved network quality conditions and a fast application start.
Q4S対応ネットワークのシナリオでは、Q4S-ALERTメソッドがサーバーによってクライアントにトリガーされ、クライアントは同じQ4S-ALERTメソッドで応答します。カウンターパートから同じQ4S-ALERTを受信した後、ネットワークが反応できるようにするために、「アラートの一時停止」期間中、サーバーによって他のアラートはトリガーされませんが、早期検出を達成するために測定が継続されます。ネットワーク品質の状態が改善され、アプリケーションが迅速に開始されます。
In the Reactive scenario: an alert notification will be sent by the server stack to the Actuator, and the Actuator will answer with an alert acknowledgement. After receiving the alert acknowledgement from the Actuator, the server stack will not send other alert notifications during the "alert-pause" period of time in order to allow the Actuator to react and trigger actions on the application or on the policy server, but measurements will continue to be taken to achieve early detection of improved network quality conditions and a fast application start.
リアクティブシナリオでは、アラート通知がサーバースタックからアクチュエータに送信され、アクチュエータはアラートの確認応答で応答します。アクチュエータからアラートの確認を受け取った後、サーバースタックは、「アラートの一時停止」期間中に他のアラート通知を送信せず、アクチュエータがアプリケーションまたはポリシーサーバーでアクションを実行してアクションをトリガーできるようにしますが、測定改善されたネットワーク品質状態の早期検出とアプリケーションの迅速な開始を実現するために引き続き取られます。
In both scenarios stated above, if after several measurement cycles, the network constraints cannot be met, the quality session is terminated. Concretely when, under all possible actions taken by Actuator, the quality remains below requirements, the session must be terminated.
上記の両方のシナリオで、いくつかの測定サイクルの後にネットワークの制約が満たされない場合、品質セッションは終了します。具体的には、アクチュエータによって実行されるすべての可能なアクションの下で、品質が要件を下回ったままの場合、セッションを終了する必要があります。
The steps to be taken in this phase depend on the measurement procedure exchanged during the Handshake phase. This document only describes the "default" procedure, but others can be used, like RTP/ RTCP [RFC3550].
このフェーズで実行する手順は、ハンドシェイクフェーズ中に交換される測定手順によって異なります。このドキュメントでは「デフォルト」の手順のみを説明していますが、RTP / RTCP [RFC3550]などの他の手順も使用できます。
Measurements of latency and jitter are made by calculating the differences in the arrival times of packets and can be achieved with little bandwidth consumption. The bandwidth measurement, on the other hand, involves higher bandwidth consumption in both directions (uplink and downlink).
待ち時間とジッターの測定は、パケットの到着時間の差を計算することによって行われ、帯域幅をほとんど消費せずに達成できます。一方、帯域幅の測定では、双方向（アップリンクとダウンリンク）での帯域幅の消費量が多くなります。
To avoid wasting unnecessary network resources, these two types of measurements will be performed in two separate stages. If the required latencies and jitters cannot be reached, it makes no sense to waste network resources measuring bandwidth. In addition, if achieving the required latency and jitter thresholds implies upgrading the quality session level, the chance of obtaining compliant bandwidth measurements without retries is higher, saving network traffic again. Therefore, the "default" procedure determines that the measurements are taken in two stages:
不要なネットワークリソースの浪費を避けるために、これらの2種類の測定は2つの別々の段階で実行されます。必要なレイテンシとジッターに到達できない場合、帯域幅を測定するネットワークリソースを無駄にしても意味がありません。さらに、必要なレイテンシとジッターのしきい値を達成することで高品質のセッションレベルがアップグレードされる場合、再試行なしで準拠帯域幅測定値を取得できる可能性が高くなり、ネットワークトラフィックが再び節約されます。したがって、「デフォルト」の手順では、測定が2つの段階で行われることが決定されます。
Stage 0: Measurement of latencies, jitters, and packet loss
ステージ0：レイテンシ、ジッター、パケット損失の測定
Stage 1: Measurement of bandwidths and packet loss
ステージ1：帯域幅とパケット損失の測定
Notice that packet loss can be measured in both stages, as all messages exchanged include a Sequence-Number header field that allows for easy packet loss detection.
交換されるすべてのメッセージには、簡単なパケット損失検出を可能にするシーケンス番号ヘッダーフィールドが含まれているため、パケット損失は両方の段階で測定できることに注意してください。
The client starts the Negotiation phase by sending a READY request using the TCP Q4S ports defined in the SDP. This READY request includes a Stage header field that indicates the measurement stage.
クライアントは、SDPで定義されたTCP Q4Sポートを使用してREADY要求を送信することにより、交渉フェーズを開始します。このREADYリクエストには、測定ステージを示すステージヘッダーフィールドが含まれています。
If either jitter, latency, or both are specified, the Negotiation phase begins with the measurement of latencies and jitters (stage 0). If none of those attributes is specified, stage 0 is skipped.
ジッター、レイテンシ、またはその両方が指定されている場合、ネゴシエーションフェーズはレイテンシとジッターの測定から始まります（ステージ0）。これらの属性のいずれも指定されていない場合、ステージ0はスキップされます。
The Stage 0 MUST start with a synchronization message exchange initiated with the client's READY message.
ステージ0は、クライアントのREADYメッセージで開始される同期メッセージ交換で開始する必要があります。
Client Request, READY message:
=========================
READY q4s://www.example.com Q4S/1.0
Stage: 0
Session-Id: 53655765
User-Agent: q4s-ua-experimental-1.0
Content-Length: 0
=========================
Server Response:
=========================
Q4S/1.0 200 OK
Session-Id: 53655765
Stage:0
Content-Length: 0
=========================
This triggers the exchange of a sequence of PING requests and responses that will lead to the calculation of RTT (latency), jitter, and packet loss.
これにより、一連のPING要求と応答の交換がトリガーされ、RTT（待ち時間）、ジッター、およびパケット損失の計算につながります。
After receiving a 200 OK, the client must send the first PING message, and the server will wait to send PINGs until the reception of this first client PING.
200 OKを受信した後、クライアントは最初のPINGメッセージを送信する必要があり、サーバーはこの最初のクライアントPINGを受信するまでPINGの送信を待機します。
The client and server MUST send PING requests to each other. The Sequence-Number header field of the first PING MUST be set to 0. The client and server will manage their own sequence numbers.
クライアントとサーバーは相互にPINGリクエストを送信する必要があります。最初のPINGのSequence-Numberヘッダーフィールドは0に設定する必要があります。クライアントとサーバーは独自のシーケンス番号を管理します。
+------------------------------------------------+
| |
| Client Server |
| |
| --------- Q4S READY 0 ---------> |
| <-------- Q4S 200 OK ----------- |
| |
| --------- Q4S PING ------------> |
| <-------- Q4S 200 OK ----------- |
| <-------- Q4S PING ------------- |
| -------- Q4S 200 OK ----------> |
| --------- Q4S PING ------------> |
| <-------- Q4S PING ------------- |
| --------- Q4S 200 OK ----------> |
| <-------- Q4S 200 OK ----------- |
| ... |
| |
+------------------------------------------------+
Figure 8: Simultaneous Exchange of PING Request and Responses
図8：PING要求と応答の同時交換
The following is an example of the PING request sent from the client and the server's response:
以下は、クライアントから送信されたPING要求とサーバーの応答の例です。
Client Request:
=========================
PING q4s://www.example.com Q4S/1.0
Session-Id: 53655765
Sequence-Number: 0
User-Agent: q4s-ua-experimental-1.0
Measurements: l=22, j=12, pl=0.20, bw=
Content-Length: 0
=========================
Server Response:
=========================
Q4S/1.0 200 OK
Session-Id: 53655765
Sequence-Number: 0
Content-Length: 0
=========================
The function of the PING method is similar to the ICMP echo request message [RFC0792]. The server MUST answer as soon as it receives the message.
PINGメソッドの機能は、ICMPエコー要求メッセージ[RFC0792]に似ています。サーバーは、メッセージを受信したらすぐに応答する必要があります。
Both endpoints MUST send Q4S PING messages with the periodicity specified in the first parameter of SDP "measurement:procedure" attribute, always using the same UDP ports and incrementing the Sequence-Number with each message.
両方のエンドポイントは、SDP "measurement：procedure"属性の最初のパラメーターで指定された周期でQ4S PINGメッセージを送信する必要があり、常に同じUDPポートを使用し、各メッセージでシーケンス番号をインクリメントします。
In the following example, the value of the first parameter of the SDP "measurement:procedure" attribute is 50 milliseconds (from the client to the server) and 60 ms (from the server to the client):
次の例では、SDPの「measurement：procedure」属性の最初のパラメーターの値は、50ミリ秒（クライアントからサーバー）および60ミリ秒（サーバーからクライアント）です。
a=measurement:procedure default(50/60,50/50,5000,256/256,256/256)
They MUST NOT wait for a response to send the next PING request. The Sequence-Number header field value is incremented sequentially and MUST start at zero. If this stage is repeated, the initial Sequence-Number MUST start at zero again.
次のPINGリクエストを送信するための応答を待ってはなりません。 Sequence-Numberヘッダーフィールドの値は順次インクリメントされ、ゼロから開始する必要があります。この段階が繰り返される場合、最初のシーケンス番号は再びゼロから開始する必要があります。
All PING requests MUST contain a Measurements header field with the values of the latency, jitter, and packet loss measured by each entity up to that moment. The client will send its measurements to the server, and the server will send its measurements to the client. Example:
すべてのPING要求には、その瞬間までに各エンティティによって測定された待ち時間、ジッター、およびパケット損失の値を含むMeasurementsヘッダーフィールドが含まれている必要があります。クライアントは測定値をサーバーに送信し、サーバーは測定値をクライアントに送信します。例：
Measurements: l=22, j=13, pl=0.10, bw=
Where "l" stands for latency, "j" for jitter, "pl" for packet loss, and "bw" for bandwidth. The bandwidth value is omitted, as it is not measured at this stage.
ここで、「l」はレイテンシ、「j」はジッタ、「pl」はパケット損失、「bw」は帯域幅を表します。この段階では測定されていないため、帯域幅の値は省略されています。
Optionally the PING request can include a Timestamp header field with the time in which the message has been sent. In the case that the header field is present, the server MUST include the header field in the response without changing the value.
オプションで、PING要求には、メッセージが送信された時刻を含むTimestampヘッダーフィールドを含めることができます。ヘッダーフィールドが存在する場合、サーバーは値を変更せずに応答にヘッダーフィールドを含める必要があります。
A minimum number of PING messages MUST be exchanged in order to be able to measure latency, jitter, and packet loss with certain accuracy (at least 256 samples are RECOMMENDED to get an accurate packet loss measurement). Both the client and the server calculate the respective measured parameter values. The mechanisms to calculate the different parameters are described in Section 7.3.
レイテンシ、ジッター、およびパケット損失を特定の精度で測定できるようにするには、最小数のPINGメッセージを交換する必要があります（正確なパケット損失測定を行うには、少なくとも256サンプルをお勧めします）。クライアントとサーバーの両方が、それぞれの測定されたパラメーター値を計算します。さまざまなパラメータを計算するメカニズムについては、7.3節で説明します。
At the end of this stage 0, there are three possibilities:
このステージ0の終わりには、3つの可能性があります。
* The latency, jitter, and packetloss constraints are reached in both directions
* レイテンシ、ジッター、およびパケットロスの制約が両方向で達成されている
* The latency, jitter, and packetloss constraints are not reached in one or both directions
* 待ち時間、ジッター、およびパケットロスの制約が一方向または両方向で到達しない
In the first case, Stage 0 is finished. The client and server are ready for Stage 1: bandwidth and packet loss measurement. The client moves to stage 1 by sending a READY message that includes the header field, "Stage: 1".
最初のケースでは、ステージ0が終了します。クライアントとサーバーはステージ1の準備ができています：帯域幅とパケット損失の測定。クライアントは、ヘッダーフィールド「ステージ：1」を含むREADYメッセージを送信して、ステージ1に移動します。
If the bandwidth constraints are either empty or have a value of zero, the Negotiation phase MUST terminate, and both client and server may initiate the Continuity phase. In this case, client moves to the Continuity phase by sending a READY message that includes the header field, "Stage: 2".
帯域幅の制約が空であるか、値が0の場合、ネゴシエーションフェーズは終了する必要があり、クライアントとサーバーの両方が継続性フェーズを開始できます。この場合、クライアントは、ヘッダーフィールド「Stage：2」を含むREADYメッセージを送信することにより、Continuityフェーズに移行します。
The second case, in which one or more quality constraints have not been met, is detailed in Section 7.5.4.
1つまたは複数の品質制約が満たされていない2番目のケースについては、セクション7.5.4で詳しく説明します。
This stage begins in a similar way to stage 0, sending a READY request over TCP. The value of the READY message's Stage header field is 1. The server answers with a Q4S 200 OK message to synchronize the initiation of the measurements as shown in Figure 9.
このステージは、ステージ0と同様の方法で始まり、TCPを介してREADY要求を送信します。 READYメッセージのステージヘッダーフィールドの値は1です。サーバーは、Q4S 200 OKメッセージで応答して、測定の開始を同期します（図9を参照）。
+------------------------------------------------+
| |
| Client Server |
| |
| --------- Q4S READY 1 -----------> |
| <-------- Q4S 200 OK ------------- |
| |
| --------- Q4S BWIDTH -----------> |
| <-------- Q4S BWIDTH ------------ |
| --------- Q4S BWIDTH -----------> |
| <-------- Q4S BWIDTH ------------ |
| ... |
| |
+------------------------------------------------+
Figure 9: Starting Bandwidth and Packet Loss Measurement
図9：帯域幅とパケット損失の測定の開始
Client Request:
=========================
READY q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0
Stage: 1
Session-Id: 53655765
Content-Length: 0
=========================
Server Response:
=========================
Q4S/1.0 200 OK
Session-Id: 53655765
Stage: 1
Content-Length: 0
=========================
Just after receiving the 200 OK, both the client and the server MUST start sending BWIDTH messages simultaneously using the UDP "q4s" ports. Section 7.3.3 describes the bandwidth measurement in detail.
200 OKを受信した直後に、クライアントとサーバーの両方がUDP "q4s"ポートを使用してBWIDTHメッセージの送信を同時に開始する必要があります。 7.3.3項では、帯域幅測定について詳しく説明します。
At the end of this stage 1, there are three possibilities:
このステージ1の最後には、3つの可能性があります。
* The bandwidth and packetloss constraints are reached in both directions.
* 帯域幅とパケット損失の制約は、双方向で達成されます。
* The bandwidth and packetloss constraints are not reached in one or both directions.
* 帯域幅とパケットロスの制約が一方向または両方向で到達していません。
In the first case, Stage 1 is finished. The client and server are ready for the Continuity phase. The client moves to this phase by sending a READY message that includes the header field, "Stage: 2". The server answer MUST be 200 OK as shown in Figure 10.
最初のケースでは、ステージ1が終了します。クライアントとサーバーは、継続フェーズの準備ができています。クライアントは、ヘッダーフィールド「ステージ：2」を含むREADYメッセージを送信して、このフェーズに移動します。図10に示すように、サーバーの応答は200 OKでなければなりません。
+------------------------------------------------+
| |
| Client Server |
| |
| --------- Q4S READY 2 --------------> |
| <---- Q4S 200 OK with trigger URI----- |
| |
| --------- HTTP GET ----------------> |
| |
| (Application starts) |
| |
+------------------------------------------------+
Figure 10: Trigger the Application Using HTTP URI
図10：HTTP URIを使用してアプリケーションをトリガーする
Client Request:
=========================
READY q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0
Stage: 2
Session-Id: 53655765
Content-Length: 0
=========================
Server Answer:
=========================
Q4S/1.0 200 OK
Date: Mon, 10 Jun 2010 10:00:01 GMT
Session-Id: 53655765
Trigger-URI: http://www.example.com/app_start
Expires: 3000
Content-Type: application/sdp
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131
(SDP not shown)
=========================
If the Trigger-URI header field is present, the client SHOULD send an HTTP request to this URI.
Trigger-URIヘッダーフィールドが存在する場合、クライアントはこのURIにHTTPリクエストを送信する必要があります（SHOULD）。
The second case, with violated network constraints, is explained in Section 7.5.4.
ネットワーク制約に違反した2番目のケースについては、セクション7.5.4で説明します。
After finishing Stage 1 of the Negotiation phase, the client and the server have each other's measured parameter values as these have been exchanged in the Measurements header fields of the PING and BWIDTH messages. If there is one or more parameters that do not comply with the uplink or downlink application constraints required, both the server and the client are aware of it.
ネゴシエーションフェーズのステージ1が完了すると、クライアントとサーバーは、PINGメッセージとBWIDTHメッセージのMeasurementsヘッダーフィールドで交換された、互いの測定されたパラメーター値を取得します。必要なアップリンクまたはダウンリンクアプリケーションの制約に準拠していないパラメーターが1つ以上ある場合、サーバーとクライアントの両方がそれを認識します。
If there is any quality parameter that does not meet the uplink or downlink quality constraints specified in the SDP message, two scenarios are possible depending on the specified alerting mode (if not present, the default value is Reactive alerting mode):
SDPメッセージで指定されたアップリンクまたはダウンリンクの品質制約を満たさない品質パラメーターがある場合、指定されたアラートモードに応じて2つのシナリオが可能です（存在しない場合、デフォルト値はリアクティブアラートモードです）。
(a) Q4S-aware-network alerting mode: the server MUST send a Q4S-ALERT message to the client including the digital Signature header field, and the client MUST answer with the same Q4S-ALERT message. The Signature header field contains the signed hash value of the SDP body in order to protect all the SDP data, and therefore it MUST contain the "measurement" parameters in the body.
（a）Q4S対応ネットワークアラートモード：サーバーはデジタル署名ヘッダーフィールドを含むQ4S-ALERTメッセージをクライアントに送信する必要があり、クライアントは同じQ4S-ALERTメッセージで応答する必要があります。 Signatureヘッダーフィールドには、すべてのSDPデータを保護するためにSDP本体の署名済みハッシュ値が含まれているため、本体に「測定」パラメーターを含める必要があります。
Server request
=========================
Q4S-ALERT q4s://www.example.com Q4S/1.0
Host: www.example.com
User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765
Content-Type: application/sdp
Content-Length: 142
v=0
o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33
s=Q4S
i=Q4S parameters
t=0 0
a=qos-level:1/2
a=alerting-mode: Q4S-aware-network
a=alert-pause:5000
a=public-address:client IP4 198.51.100.51
a=public-address:server IP4 198.51.100.58
a=latency:40
a=jitter:10/10
a=bandwidth:20/6000
a=packetloss:0.50/0.50
a=flow:app downlink TCP/10000-20000
a=flow:app uplink TCP/56000
a=flow:q4s downlink UDP/55000
a=flow:q4s downlink TCP/55001
a=flow:q4s uplink UDP/56000
a=flow:q4s uplink TCP/56001
a=measurement:procedure default(50/50,50/50,5000,256/256,256/256)
a=measurement:latency 30
a=measurement:jitter 6/4
a=measurement:bandwidth 200/4000
a=measurement:packetloss 0.20/0.33
=========================
At this point, both the client and server keep on measuring but without sending new Q4S-ALERT messages during the "alert-pause" milliseconds.
この時点で、クライアントとサーバーの両方が測定を続けますが、「アラート一時停止」ミリ秒の間、新しいQ4S-ALERTメッセージを送信しません。
(b) Reactive alerting mode: the server stack MUST send an alert notification to the Actuator, and the Actuator MUST answer with an acknowledgement to the received alert notification. The alert notification sent to the Actuator by the server stack doesn't follow Q4S message style but should have all the information the Actuator will need for the actions to be taken, which will be implementation dependent.
（b）リアクティブアラートモード：サーバースタックは、アクチュエータにアラート通知を送信する必要があり、アクチュエータは、受信したアラート通知に対する確認応答で応答する必要があります。サーバースタックによってアクチュエータに送信されるアラート通知は、Q4Sメッセージスタイルに準拠していませんが、実行されるアクションにアクチュエータが必要とするすべての情報が必要です。これは実装に依存します。
At this point during Negotiation phase, both the client and server keep on measuring without sending new alert notifications to the Actuator during the "alert-pause" milliseconds specified in the SDP. This way, both client and server will detect any improvement in network conditions as soon as the network reacts. The application can start as soon as the number of measurements indicated in the "measurement:procedure" attribute indicates that the quality parameters are met.
ネゴシエーションフェーズのこの時点では、クライアントとサーバーの両方が、SDPで指定された「アラート一時停止」ミリ秒の間、アクチュエータに新しいアラート通知を送信せずに測定を続けます。このように、ネットワークが反応するとすぐに、クライアントとサーバーの両方がネットワーク状態の改善を検出します。 「measurement：procedure」属性に示されている測定値の数が、品質パラメーターが満たされていることを示すとすぐに、アプリケーションを開始できます。
The same applies to Continuity phase: the measurement dialog between client and server must not be interrupted by any possible ALERT message.
同じことが継続フェーズにも当てはまります。クライアントとサーバー間の測定ダイアログは、起こり得るALERTメッセージによって中断されてはなりません。
The actuator receives notifications of unmet requirements from the Q4S server stack and acts upon the application or the network policy server, according to logic out of scope of this protocol.
アクチュエータは、Q4Sサーバースタックから満たされていない要件の通知を受け取り、このプロトコルの範囲外のロジックに従って、アプリケーションまたはネットワークポリシーサーバーに作用します。
The Actuator logic activates mechanisms at the application level and/ or the network level based on a quality level dictionary, in which the meaning of each level is implementation dependent, and each level involves different actions based on rules to keep a certain user experience quality.
アクチュエータロジックは、品質レベルディクショナリに基づいて、アプリケーションレベルまたはネットワークレベル、あるいはその両方でメカニズムをアクティブにします。各レベルの意味は実装に依存し、各レベルには、特定のユーザーエクスペリエンス品質を維持するためのルールに基づくさまざまなアクションが含まれます。
The type of actions that an Actuator can take at the application level are application dependent and MAY involve:
アクチュエータがアプリケーションレベルで実行できるアクションのタイプは、アプリケーションに依存しており、以下を伴う場合があります。
* Reduction of application functionalities, such as limitation of application speed or application options.
* アプリケーション速度やアプリケーションオプションの制限など、アプリケーション機能の削減。
* Reduction of application resources usage, such as reduction of frames per second in a video application or any other parameter modification in order to adapt to network conditions.
* ビデオリソースの1秒あたりのフレーム数の削減などのアプリケーションリソース使用量の削減、またはネットワークの状態に適応するためのその他のパラメーター変更。
Apart from actions at the application level, the Actuator MAY act at the network level if a network policy server is available.
アプリケーションレベルでのアクションとは別に、ネットワークポリシーサーバーが使用可能な場合、アクチュエータはネットワークレベルで動作する場合があります。
A network policy server may be part of the Reactive scenario, and it is in charge of managing network quality provision. A network policy server may implement all or some of these features (but implementation is not exclusive to):
ネットワークポリシーサーバーは、リアクティブシナリオの一部である場合があり、ネットワーク品質の提供の管理を担当します。ネットワークポリシーサーバーは、これらの機能のすべてまたは一部を実装できます（ただし、実装はこれに限定されません）。
* Server validation in terms of quality constraints
* 品質の制約に関するサーバーの検証
* Authentication (Signature validation) and security (blocking of malicious clients)
* 認証（署名の検証）とセキュリティ（悪意のあるクライアントのブロック）
* Policy rules (the following rules are only examples):
* ポリシー規則（以下の規則は単なる例です）：
- Maximum quality level allowed for the ACP
- ACPに許可される最大品質レベル
- Time bands allowed for providing quality sessions
- 質の高いセッションを提供できる時間帯
- Number of simultaneous quality sessions allowed
- 許可される同時品質セッションの数
- Maximum time used by allowed quality sessions
- 許可された品質のセッションで使用された最大時間
- Etc.
- 等。
If any of the policy rules fail, a Q4S-ALERT message MUST be answered by a 6xx error indicating the cause.
ポリシールールのいずれかが失敗した場合、Q4S-ALERTメッセージは、原因を示す6xxエラーで応答する必要があります。
If any constraint was violated, the server MAY trigger a Q4S-ALERT asking for a higher "qos-level" attribute. The maximum "qos-level" allowed is 9 for both uplink and downlink.
制約に違反した場合、サーバーはより高い「QOSレベル」属性を要求するQ4S-ALERTをトリガーしてもよい（MAY）。許可される最大の「QOSレベル」は、アップリンクとダウンリンクの両方で9です。
If the "qos-level" has reached the maximum value for the downlink or uplink without matching the constraints, then a CANCEL request MUST be sent by the client using the TCP port determined in the Handshake phase in order to release the session. In reaction to the reception of the CANCEL request, the server MUST send a CANCEL request, too. If no CANCEL request is received, the expiration time cancels the session on the server side.
「QOSレベル」が制約に一致せずにダウンリンクまたはアップリンクの最大値に達した場合、セッションを解放するために、ハンドシェイクフェーズで決定されたTCPポートを使用してクライアントからCANCEL要求を送信する必要があります。 CANCELリクエストの受信に応じて、サーバーもCANCELリクエストを送信する必要があります。 CANCEL要求が受信されない場合、有効期限はサーバー側のセッションをキャンセルします。
Client Request:
=========================
CANCEL q4s://www.example.com Q4S/1.0
User-Agent: q4s-ua-experimental-1.0
Session-Id: 53655765
Content-Type: application/sdp
Content-Length: 142
(SDP not shown)
=========================
Server Request in reaction to Client Request:
=========================
CANCEL q4s://www.example.com Q4S/1.0
Session-Id: 53655765
Expires: 0
Content-Type: application/sdp
Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4
Content-Length: 131
(SDP not shown)
=========================
During the Negotiation phase, latency, jitter, bandwidth, and packet loss have been measured. During the Continuity phase, bandwidth will not be measured again because bandwidth measurements may disturb application performance.
ネゴシエーションフェーズでは、遅延、ジッター、帯域幅、およびパケット損失が測定されています。継続性フェーズでは、帯域幅の測定がアプリケーションのパフォーマンスを妨げる可能性があるため、帯域幅は再度測定されません。
This phase is supposed to be executed at the same time as the real-time application is being used.
このフェーズは、リアルタイムアプリケーションの使用と同時に実行されることになっています。
This document only covers the "default" procedure. The continuity operation with the "default" procedure is based on a sliding window of samples. The number of samples involved in the sliding window may be different for jitter and latency than for packet loss calculations according to the fifth and sixth parameters of the "measurement:procedure" attribute. In the example, shown in Figure 11, the jitter and latency sliding window comprises 40 samples, whereas the size of the packet loss sliding window is 100 samples:
このドキュメントでは、「デフォルト」の手順のみを扱います。 「デフォルト」の手順による連続性操作は、サンプルのスライディングウィンドウに基づいています。スライディングウィンドウに含まれるサンプルの数は、「measurement：procedure」属性の5番目と6番目のパラメーターに従って、ジッターとレイテンシの場合とパケット損失計算の場合とで異なる場合があります。図11に示す例では、ジッターと遅延のスライディングウィンドウは40サンプルで構成されていますが、パケット損失のスライディングウィンドウのサイズは100サンプルです。
a=measurement:procedure default(50/50,75/75,5000,40/40,100/100)
In addition, the sizes of these windows are configurable per direction: uplink and downlink values may differ.
さらに、これらのウィンドウのサイズは方向ごとに構成可能です。アップリンクとダウンリンクの値は異なる場合があります。
PING requests are sent continuously (in both directions), and when the Sequence-Number header field reaches the maximum value, the client continues sending PING messages with the Sequence-Number header field starting again at zero. When the server PING Sequence-Number header field reaches the maximum value, it does the same, starting again from zero.
PING要求は継続的に（両方向に）送信され、Sequence-Numberヘッダーフィールドが最大値に達すると、クライアントはSequence-Numberヘッダーフィールドがゼロから始まるPINGメッセージを送信し続けます。サーバーのPING Sequence-Numberヘッダーフィールドが最大値に達すると、ゼロから再び同じように動作します。
On the client side, the measured values of downlink jitter, downlink packet loss, and latency are calculated using the last samples, discarding older ones, in a sliding window schema.
クライアント側では、ダウンリンクジッタ、ダウンリンクパケット損失、および遅延の測定値は、最後のサンプルを使用して計算され、古いウィンドウはスライディングウィンドウスキーマで破棄されます。
+--------------------------------------------------+
| |
| 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56 |
| A A |
| | | |
| +-----------------------------------+ |
| |
+--------------------------------------------------+
Figure 11: Sliding Samples Window
図11：スライド式サンプルウィンドウ
Only if the server detects that the measured values (downlink or uplink jitter, packet loss, or latency) are not reaching the quality constraints, a Q4S-ALERT is triggered and sent either to the client or to the Actuator, depending on the alerting mode, and the "alert-pause" timer is started.
測定値（ダウンリンクまたはアップリンクのジッター、パケット損失、または遅延）が品質の制約に達していないことをサーバーが検出した場合のみ、Q4S-ALERTがトリガーされ、アラートモードに応じてクライアントまたはアクチュエーターに送信されます、「アラート一時停止」タイマーが開始されます。
In the Q4S-aware-network alerting mode shown in Figure 12, if the client receives a Q4S-ALERT message, it MUST answer by sending the Q4S-ALERT request message including the SDP (with its corresponding digital signature) back to the server.
図12に示すQ4S対応ネットワークアラートモードでは、クライアントがQ4S-ALERTメッセージを受信した場合、SDP（対応するデジタル署名付き）を含むQ4S-ALERTリクエストメッセージをサーバーに送信して応答する必要があります。
Both client and server will keep performing measurements, but Q4S-ALERT messages MUST NOT be sent during "alert-pause" milliseconds. The operations needed to act on the network and the agents in charge of them are out of scope of this document.
クライアントとサーバーの両方が測定を実行し続けますが、Q4S-ALERTメッセージは「alert-pause」ミリ秒の間は送信してはなりません。ネットワークとそれらを担当するエージェントに作用するために必要な操作は、このドキュメントの範囲外です。
+------------------------------------------------+
| |
| Client Server |
| |
| ... |
| ----------- PING ----------> |
| <--------- 200 OK ---------- |
| <------- Q4S-ALERT --------- |
| -------- Q4S-ALERT --------> |
| <---------- PING ----------- |
| ---------- 200 OK ---------> |
| ----------- PING ----------> |
| <--------- 200 OK ---------- |
| <---------- PING ----------- |
| ---------- 200 OK ---------> |
| ... |
| |
+------------------------------------------------+
Figure 12: Continuity in Q4S-Aware-Network Alerting Mode
図12：Q4S対応ネットワークアラートモードの継続性
In the Reactive scenario shown in Figure 13, if the server detects that the measured values (downlink or uplink jitter, packet loss, or latency) are not reaching the quality constraints, an alert notification is triggered and sent to the Actuator. The Actuator MUST then answer to the server stack with an alert acknowledgement.
図13に示すリアクティブシナリオでは、測定値（ダウンリンクまたはアップリンクのジッター、パケット損失、または遅延）が品質の制約に達していないことをサーバーが検出すると、アラート通知がトリガーされ、アクチュエーターに送信されます。次に、アクチュエータは、アラート確認でサーバースタックに応答する必要があります。
The measurement dialog between the client and the server MUST NOT be interrupted by any possible ALERT message.
クライアントとサーバー間の測定ダイアログは、可能性のあるALERTメッセージによって中断されてはいけません。
+------------------------------------------------+
| |
| Client Server Actuator |
| ... |
| --- PING ----------> |
| <-- 200 OK---------- |
| <----- PING -------- |
| <--- 200 OK -------- ---- alert |
| notification --> |
| |
| --- PING ----------> <--- alert |
| acknowledge --- |
| <-- 200 OK---------- |
| <----- PING -------- |
| --- 200 OK --------> |
| ... |
| |
+------------------------------------------------+
Figure 13: Continuity in Reactive Alerting Mode
図13：リアクティブアラートモードの継続性
The Termination phase is the endpoint for the established Q4S session that is reached in the following cases:
終了フェーズは、次の場合に到達する確立されたQ4Sセッションのエンドポイントです。
* A CANCEL message has been received. The client sends a CANCEL message due to the network's inability to meet the required quality constraints. The client and server application will be notified by their respective Q4S stacks.
* CANCELメッセージが受信されました。ネットワークは必要な品質の制約を満たすことができないため、クライアントはCANCELメッセージを送信します。クライアントおよびサーバーアプリケーションは、それぞれのQ4Sスタックによって通知されます。
* Session expires: if after the Expires time, no client or server activity is detected, that end cancels the session.
* セッションの有効期限：Expires時間の経過後、クライアントまたはサーバーのアクティビティが検出されない場合、その終了によりセッションがキャンセルされます。
* A BEGIN message has been received by the server. The pre-existing Q4S quality session is canceled, and a new session will be initiated.
* BEGINメッセージがサーバーによって受信されました。既存のQ4S品質セッションがキャンセルされ、新しいセッションが開始されます。
The meaning of the Termination phase in terms of the release of resources or accounting is application dependent and out of scope of the Q4S protocol.
リソースまたはアカウンティングの解放に関する終了フェーズの意味は、アプリケーションに依存し、Q4Sプロトコルの範囲外です。
In the Reactive alerting mode, Q4S CANCEL messages received by the Q4S server must cause the server stack to send cancel notifications to the Actuator in order to release possible assigned resources for the session.
リアクティブアラートモードでは、Q4SサーバーがQ4S CANCELメッセージを受信すると、セッションに割り当てられている可能性のあるリソースを解放するために、サーバースタックがアクチュエータにキャンセル通知を送信する必要があります。
A session may finish due to several reasons (client shutdown, client CANCEL request, constraints not reached, etc.), and any session finished MUST release the assigned resources.
いくつかの理由（クライアントのシャットダウン、クライアントのCANCEL要求、制約に達していないなど）によりセッションが終了することがあり、終了したセッションは割り当てられたリソースを解放する必要があります。
In order to release the assigned server resources for the session, the Expires header field indicates the maximum interval of time without exchanging any Q4S message.
セッションに割り当てられたサーバーリソースを解放するために、Expiresヘッダーフィールドは、Q4Sメッセージを交換せずに最大時間間隔を示します。
Depending on the nature of the application, the quality constraints to be reached may evolve, changing some or all quality constraint values in any direction.
アプリケーションの性質に応じて、到達する品質制約は進化し、一部またはすべての品質制約値を任意の方向に変更します。
The client MUST be able to deal with this possibility. When the server sends an SDP document attached to a response (200 OK or Q4S-ALERT, etc.), the client MUST take all the new received values, overriding any previous value in use.
クライアントはこの可能性に対処できなければなりません。サーバーが応答に添付されたSDPドキュメント（200 OKまたはQ4S-ALERTなど）を送信する場合、クライアントは使用中の以前の値を上書きして、すべての新しい受信値を取得する必要があります。
The dynamic changes on the quality constraints can be a result of two possibilities:
品質制約の動的な変更は、2つの可能性の結果である可能性があります。
* The application communicates to the Q4S server a change in the constraints. In this case, the application requirements can evolve, and the Q4S server will be aware of them.
* アプリケーションは、制約の変更をQ4Sサーバーに通知します。この場合、アプリケーション要件は進化する可能性があり、Q4Sサーバーはそれらを認識します。
* The application uses TCP flows. In that case, in order to guarantee a constant throughput, the nature of TCP behavior forces the use of a composite constraint function, which depends on RTT, packet loss, and a window control mechanism implemented in each TCP stack.
* アプリケーションはTCPフローを使用します。その場合、一定のスループットを保証するために、TCP動作の性質により、複合制約関数の使用が強制されます。これは、RTT、パケット損失、および各TCPスタックに実装されているウィンドウ制御メカニズムに依存します。
TCP throughput can be less than actual bandwidth if the Bandwidth-Delay Product (BDP) is large, or if the network suffers from a high packet loss rate. In both cases, TCP congestion control algorithms may result in a suboptimal performance.
帯域幅遅延積（BDP）が大きい場合、またはネットワークのパケット損失率が高い場合、TCPスループットは実際の帯域幅よりも小さくなることがあります。どちらの場合も、TCP輻輳制御アルゴリズムは、最適とは言えないパフォーマンスを引き起こす可能性があります。
Different TCP congestion control implementations like Reno [RENO], High Speed TCP [RFC3649], CUBIC [CUBIC], Compound TCP (CTCP) [CTCP], etc., reach different throughputs under the same network conditions of RTT and packet loss. In all cases, depending on the RTT-measured value, the Q4S server could dynamically change the packetloss constraints (defined in the SDP) in order to make it possible to reach a required throughput or vice versa (using "measurement:packetloss" to change dynamically the latency constraints).
Reno [RENO]、High Speed TCP [RFC3649]、CUBIC [CUBIC]、Compound TCP（CTCP）[CTCP]などのさまざまなTCP輻輳制御実装は、RTTとパケット損失の同じネットワーク条件下で異なるスループットに到達します。すべてのケースで、RTTで測定された値に応じて、Q4Sサーバーはパケット損失の制約（SDPで定義）を動的に変更して、必要なスループットに到達できるようにするか、その逆（「測定：パケット損失」を使用してレイテンシ制約を動的に）。
A general guideline for calculating the packet loss constraint and the RTT constraint consists of approximating the throughput by using a simplified formula, which should take into account the TCP stack implementation of the receiver, in addition to the RTT and packet loss:
パケット損失制約とRTT制約を計算するための一般的なガイドラインは、RTTとパケット損失に加えて、レシーバーのTCPスタック実装を考慮に入れる必要がある簡略化された式を使用してスループットを概算することで構成されています。
Th= Function( RTT, packet loss, ...)
Th =関数（RTT、パケット損失、...）
Then, depending on RTT-measured values, set dynamically the packet loss constraint.
次に、RTT測定値に応じて、パケット損失の制約を動的に設定します。
It is possible to easily calculate a worst-case boundary for the Reno algorithm, which should ensure for all algorithms that the target throughput is actually achieved, except that high-speed algorithms will then have even larger throughput if more bandwidth is available.
Renoアルゴリズムの最悪の場合の境界を簡単に計算することができます。これにより、すべてのアルゴリズムでターゲットスループットが実際に達成されることが保証されます。ただし、より高速なアルゴリズムでは、より多くの帯域幅が利用可能であれば、さらに大きなスループットが得られます。
For the Reno algorithm, the Mathis formula may be used [RENO] for the upper bound on the throughput:
Renoアルゴリズムでは、スループットの上限にMathis式を使用できます[RENO]。
Th <= (MSS/RTT)*(1 / sqrt{p})
In the absence of packet loss, a practical limit for the TCP throughput is the receiver_window_size divided by the RTT. However, if the TCP implementation uses a window scale option, this limit can reach the available bandwidth value.
パケット損失がない場合、TCPスループットの実際的な制限は、receiver_window_sizeをRTTで割った値です。ただし、TCP実装がウィンドウスケールオプションを使用している場合、この制限は使用可能な帯域幅の値に達する可能性があります。
Each time the server detects a violation of constraints, the alert mechanism is triggered, the "alert-pause" timer is started, and the "qos-level" is increased. When this happens repeatedly, and the "qos-level" reaches its maximum value (value 9), the session is canceled. But when the violation of constraints stops before reaching "qos-level" maximum value, the recovery mechanism allows for the "qos-level" upgrade gradually.
サーバーが制約違反を検出するたびに、アラートメカニズムがトリガーされ、「アラート一時停止」タイマーが開始され、「QOSレベル」が増加します。これが繰り返し発生し、「QOSレベル」が最大値（値9）に達すると、セッションはキャンセルされます。ただし、制約の違反が「QOSレベル」の最大値に達する前に停止すると、回復メカニズムにより「QOSレベル」のアップグレードが徐々に可能になります。
This downgrade and upgrade of "qos-level" is explained with the following example:
この「qos-level」のダウングレードとアップグレードについて、次の例で説明します。
1. A Q4S session is initiated successfully with "qos-level=0".
1. Q4Sセッションは「qos-level = 0」で正常に開始されます。
2. During the Continuity phase, violation of constraints is detected; the "qos-level" is increased to 1, a Q4S-ALERT is sent by the server to the client, and an "alert-pause" timer is started.
2. 継続フェーズ中に、制約違反が検出されます。 「QOSレベル」が1に増加し、Q4S-ALERTがサーバーからクライアントに送信され、「アラート一時停止」タイマーが開始されます。
3. The "alert-pause" timer expires, and still a violation of constraints is detected; the "qos-level" is increased to 2, a Q4S-ALERT is sent by the server to the client, and an "alert-pause" timer is started.
3. 「アラート一時停止」タイマーが期限切れになっても、制約違反が検出されます。 「qos-level」が2に増加し、Q4S-ALERTがサーバーからクライアントに送信され、「alert-pause」タイマーが開始されます。
4. The "alert-pause" timer expires, but the violation of constraints has stopped; the "recovery-pause" timer is started.
4. 「アラート一時停止」タイマーが期限切れになったが、制約違反が停止した。 「リカバリー一時停止」タイマーが開始されます。
5. The "recovery-pause" timer expires, and no violation of constraints has been detected. Meanwhile, the "qos-level" is decreased to 1, a Q4S-RECOVERY is sent by the server to the client, and the "recovery-pause" timer is started again.
5. 「リカバリー一時停止」タイマーが期限切れになり、制約違反は検出されていません。一方、「qos-level」が1に減少し、Q4S-RECOVERYがサーバーからクライアントに送信され、「recovery-pause」タイマーが再び開始されます。
6. The "recovery-pause" timer expires again, and no violation of constraints has been detected. Meanwhile, the "qos-level" is decreased to 0, and a Q4S-RECOVERY is sent by the server to the client. The "recovery-pause" timer is not started this time as the "qos-level" has reached its initial value.
6. 「回復一時停止」タイマーが再び期限切れになり、制約違反は検出されていません。一方、「qos-level」は0に減少し、Q4S-RECOVERYがサーバーからクライアントに送信されます。 「qos-level」が初期値に達したため、今回は「recovery-pause」タイマーは開始されません。
When the network configuration allows for the possibility of managing Q4S flows and application flows independently (either is a network-based QoS or a Q4S-aware network), the "qos-level" downgrade process could be managed more efficiently using a strategy that allows for carrying out "qos-level" downgrades excluding application flows from SDP dynamically. The Q4S flows would be downgraded to allow for measurements on a lower quality level without interference of the application flows. A Q4S client MUST allow this kind of SDP modification by the server.
ネットワーク構成でQ4Sフローとアプリケーションフローを個別に管理できる場合（ネットワークベースのQoSまたはQ4S対応ネットワークのいずれか）、「qosレベル」のダウングレードプロセスは、 SDPからのアプリケーションフローを動的に除外する「QOSレベル」のダウングレードを実行するため。 Q4Sフローはダウングレードされ、アプリケーションフローの干渉なしに、より低い品質レベルでの測定が可能になります。 Q4Sクライアントは、サーバーによるこの種のSDP変更を許可する必要があります。
Periodically (every several minutes, depending on the implementation) a Q4S-ALERT could be triggered, in which the level is downgraded for Q4S flows, excluding application flows from the embedded SDP of that request.
定期的（実装によっては数分ごと）にQ4S-ALERTがトリガーされ、そのリクエストの組み込みSDPからのアプリケーションフローを除いて、Q4Sフローのレベルがダウングレードされます。
This mechanism allows the measurement at lower levels of quality while application flows continue using a higher "qos-level" value.
このメカニズムにより、アプリケーションフローはより高い「QOSレベル」値を使用し続けながら、より低い品質レベルでの測定が可能になります。
* If the measurements in the lower level meet the quality constraints, then a Q4S-RECOVERY message to this lower "qos-level" may be triggered, in which the SDP includes the application flows in addition to the Q4S flows.
* より低いレベルの測定値が品質の制約を満たす場合、このより低い「QOSレベル」へのQ4S-RECOVERYメッセージがトリガーされ、SDPにはQ4Sフローに加えてアプリケーションフローが含まれます。
* If the measurements in the lower level do not meet the constraints, then a new Q4S-ALERT to the previous "qos-level" MUST be triggered, in which the SDP includes only the Q4S flows.
* 下位レベルの測定が制約を満たさない場合、SDPにQ4Sフローのみが含まれる、以前の「QOSレベル」への新しいQ4S-ALERTをトリガーする必要があります。
+------------------------------------------------+
| |
| qos-level |
| A |
| | |
| 4| |
| | |
| 3| +------+ |
| | | | |
| 2| +----+ +----+ +--- |
| | | | | |
| 1| +----+ +-----+ |
| | | |
| 0+---+---------------------------------> time |
| |
+------------------------------------------------+
Figure 14: Possible Evolution of "qos-level"
図14：「QOSレベル」の可能な進化
This mechanism, illustrated in Figure 14, avoids the risk of disturbing the application while the measurements are being run in lower levels. However, this optional optimization of resources MUST be used carefully.
図14に示されているこのメカニズムは、測定が低いレベルで実行されている間にアプリケーションを妨害するリスクを回避します。ただし、リソースのこのオプションの最適化は慎重に使用する必要があります。
The chosen period to measure a lower "qos-level" is implementation dependent. Therefore, it is not included as a "measurement:procedure" parameter. It is RECOMMENDED to use a large value, such as 20 minutes.
より低い「QOSレベル」を測定するために選択された期間は、実装によって異なります。したがって、「measurement：procedure」パラメーターとして含まれていません。 20分などの大きな値を使用することをお勧めします。
In order to allow peer-to-peer applications, a Q4S User Agent (UA) MUST be able to assume both the client and server role. The role assumed depends on who sends the first message.
ピアツーピアアプリケーションを許可するには、Q4Sユーザーエージェント（UA）がクライアントとサーバーの両方の役割を引き受けることができる必要があります。想定される役割は、最初のメッセージの送信者によって異なります。
In a communication between two UAs, the UA that first sends the Q4S BEGIN request to start the Handshake phase shall assume the client role.
2つのUA間の通信では、最初にQ4S BEGINリクエストを送信して、ハンドシェイクフェーズを開始するUAがクライアントの役割を引き受けます。
If both UAs send the BEGIN request at the same time, they will wait for a random time to restart again as shown in Figure 15.
両方のUAがBEGINリクエストを同時に送信すると、図15に示すように、ランダムな時間待ってから再起動します。
Otherwise, an UA may be configured to act only as server (e.g., content provider's side).
そうでない場合、UAはサーバー（コンテンツプロバイダー側など）としてのみ機能するように構成できます。
+-----------------------------------------------+
| |
| UA(Client) UA(Server) |
| |
| -------- Q4S BEGIN -------------> |
| <------- Q4S BEGIN -------------- |
| |
| ------- Q4S BEGIN --------------> |
| <------ Q4S 200 OK -------------- |
| |
| |
+-----------------------------------------------+
Figure 15: P2P Roles
図15：P2Pロール
A Q4S session is intended to be used for an application. This means that for using the application, the client MUST establish only one Q4S session against the server. Indeed, the relation between the Session-Id and the application is 1 to 1.
Q4Sセッションは、アプリケーションで使用するためのものです。つまり、アプリケーションを使用する場合、クライアントはサーバーに対して1つのQ4Sセッションのみを確立する必要があります。実際、Session-Idとアプリケーションの関係は1対1です。
If a user wants to participate in several independent Q4S sessions simultaneously against different servers (or against the same server), it can execute different Q4S clients to establish separately different Q4S sessions, but it is NOT RECOMMENDED because:
ユーザーが異なるサーバー（または同じサーバー）に対して同時に複数の独立したQ4Sセッションに参加したい場合、異なるQ4Sクライアントを実行して別々に異なるQ4Sセッションを確立できますが、次の理由からお勧めできません。
* The establishment of a new Q4S session may affect other running applications over other Q4S sessions during bandwidth measurement.
* 新しいQ4Sセッションの確立は、帯域幅測定中に、他のQ4Sセッションよりも実行中の他のアプリケーションに影響を与える可能性があります。
* If the Negotiation phase is executed separately before running any application, the summation of bandwidth requirements could not be met when the applications are running in parallel.
* アプリケーションを実行する前にネゴシエーションフェーズを個別に実行すると、アプリケーションが並列で実行されている場合、帯域幅要件の合計を満たせなくなります。
A Q4S client has different behaviors. We will use letters X, Y, and Z to designate each different behavior (follow the letters in Figure 16 and their descriptions below).
Q4Sクライアントにはさまざまな動作があります。 X、Y、Zの文字を使用して、それぞれの動作を指定します（図16の文字と以下の説明に従ってください）。
X) When it sends messages over TCP (methods BEGIN, READY, Q4S-ALERT, Q4S-RECOVERY, and CANCEL), it behaves strictly like a state machine that sends requests and waits for responses. Depending on the response type, it enters into a new state.
X）TCP経由でメッセージを送信する場合（メソッドBEGIN、READY、Q4S-ALERT、Q4S-RECOVERY、およびCANCEL）、要求を送信して応答を待機するステートマシンとまったく同じように動作します。応答タイプに応じて、新しい状態になります。
When it sends UDP messages (methods PING and BWIDTH), a Q4S client is not strictly a state machine that sends messages and waits for responses because of the following:
UDPメッセージ（メソッドPINGおよびBWIDTH）を送信する場合、Q4Sクライアントは厳密にはメッセージを送信し、次の理由により応答を待機するステートマシンではありません。
Y) During the measurement of latency, jitter, and packet loss, the PING requests are sent periodically, not just after receiving the response to the previous request. In addition, the client MUST answer the PING requests coming from the server, therefore the client assumes temporarily the role of a server.
Y）待ち時間、ジッター、およびパケット損失の測定中、PING要求は、前の要求への応答を受信した直後ではなく、定期的に送信されます。さらに、クライアントはサーバーからのPING要求に応答する必要があるため、クライアントは一時的にサーバーの役割を引き受けます。
Z) During the bandwidth and packet loss measurement stage, the client does not expect to receive responses when sending BWIDTH requests to the server. In addition, it MUST receive and process all server messages in order to achieve the downlink measurement.
Z）帯域幅とパケット損失の測定段階では、クライアントはBWIDTH要求をサーバーに送信するときに応答を受信することを期待していません。さらに、ダウンリンク測定を実現するために、すべてのサーバーメッセージを受信して処理する必要があります。
The Q4S-ALERT and CANCEL may have a conventional answer if an error is produced, otherwise the corresponding answer is formatted as a request message.
Q4S-ALERTとCANCELは、エラーが発生した場合、従来の回答を持つ可能性があります。それ以外の場合、対応する回答は要求メッセージとしてフォーマットされます。
+-----------+------------------------+-----------+-----------+
| Handshake | Negotiation |Continuity |Termination|
| Phase | Phase | Phase | Phase |
| | | | |
| X ---------> Y --> X --> Z --> X ---> Y --> X ---> X |
| | A | A | | A | | |
| | | | | | | | | | |
| | +-----+ +-----+ | +-----+ | |
| | | | |
+------------------------------------------------+-----------+
Figure 16: Phases and Client Behaviors
図16：フェーズとクライアントの動作
A valid Q4S request formulated by a client MUST, at a minimum, contain the following header fields:
クライアントによって作成された有効なQ4Sリクエストには、少なくとも次のヘッダーフィールドが含まれている必要があります。
If no SDP is included: the header fields Session-Id and Sequence-Number are mandatory.
SDPが含まれていない場合：ヘッダーフィールドSession-IdおよびSequence-Numberは必須です。
If SDP is included: the Session-Id is embedded into the SDP, therefore the inclusion of the Session-Id header field is optional, but if present, must have the same value. Measurements are embedded into the SDP only for Q4S-ALERT messages in order to be signed.
SDPが含まれている場合：Session-IdはSDPに埋め込まれているため、Session-Idヘッダーフィールドを含めることはオプションですが、存在する場合は同じ値にする必要があります。署名するために、Q4S-ALERTメッセージの場合のみ、測定値がSDPに埋め込まれます。
At any time, if the server sends new SDP with updated values, the client MUST take it into account.
いつでも、サーバーが更新された値で新しいSDPを送信する場合、クライアントはそれを考慮する必要があります。
If a server does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message.
サーバーが要求のヘッダーフィールドを理解しない場合（つまり、ヘッダーフィールドがこの仕様またはサポートされている拡張機能で定義されていない場合）、サーバーはそのヘッダーフィールドを無視してメッセージの処理を続行する必要があります。
The role of the server is changed at Negotiation and Continuity phases, in which the server MUST send packets to measure jitter, latency, and bandwidth. Therefore, the different behaviors of the server are (follow the letters in Figure 17 and their descriptions below):
サーバーの役割は、ネゴシエーションおよび継続フェーズで変更されます。このフェーズでは、サーバーはパケットを送信して、ジッター、遅延、および帯域幅を測定する必要があります。したがって、サーバーのさまざまな動作は次のとおりです（図17の文字と以下の説明に従ってください）。
R) When the client sends messages over TCP (methods BEGIN, READY Q4S-ALERT, Q4S-RECOVERY, and CANCEL), it behaves strictly like a state machine that receives messages and sends responses.
R）クライアントがTCP経由でメッセージを送信する場合（メソッドBEGIN、READY Q4S-ALERT、Q4S-RECOVERY、およびCANCEL）、メッセージを受信して応答を送信するステートマシンとまったく同じように動作します。
When the client begins to send UDP messages (methods PING and BWIDTH), a Q4S server is not strictly a state machine that receives messages and sends responses because of the following:
クライアントがUDPメッセージ（メソッドPINGおよびBWIDTH）の送信を開始すると、Q4Sサーバーは厳密にはメッセージを受信して応答を送信するステートマシンではありません。
S) During the measurement of latency, jitter, and packet loss, the PING requests are sent periodically by the client and also by the server. In this case, the server behaves as a server answering client requests but also behaves temporarily as a client, sending PING requests toward the client and receiving responses.
S）レイテンシ、ジッター、およびパケット損失の測定中、PING要求はクライアントとサーバーによって定期的に送信されます。この場合、サーバーはクライアント要求に応答するサーバーとして動作しますが、一時的にクライアントとして動作し、PING要求をクライアントに送信して応答を受信します。
T) During bandwidth and packet loss measurement, the server sends BWIDTH requests to the client. In addition, it MUST receive and process client messages in order to achieve the uplink measurement.
T）帯域幅とパケット損失の測定中、サーバーはBWIDTH要求をクライアントに送信します。さらに、アップリンク測定を達成するために、クライアントメッセージを受信して処理する必要があります。
The Q4S-ALERT and CANCEL may have a conventional answer if an error is produced, otherwise the corresponding answer is formatted as a request message.
エラーが生成された場合、Q4S-ALERTおよびCANCELには従来の回答が含まれる場合があります。そうでない場合、対応する回答は要求メッセージとしてフォーマットされます。
+-----------+------------------------+-----------+-----------+
| Handshake | Negotiation |Continuity |Termination|
| Phase | Phase | Phase | Phase |
| | | | |
| R ---------> S --> R --> T --> R ---> S --> R ---> R |
| | A | A | | A | | |
| | | | | | | | | | |
| | +-----+ +-----+ | +-----+ | |
| | | | |
+------------------------------------------------+-----------+
Figure 17: Phases and Server Behaviors
図17：フェーズとサーバーの動作
To provide a default configuration, it would be good if the client had a configurable set of quality headers in the implementation settings menu. Otherwise, these quality headers will not be present in the first message.
デフォルトの構成を提供するには、クライアントが実装設定メニューに構成可能な品質ヘッダーのセットを持っているとよいでしょう。そうでない場合、これらの品質ヘッダーは最初のメッセージに存在しません。
Different business models (out of scope of this proposal) may be achieved: depending on who pays for the quality session, the server can accept certain client parameters sent in the first message, or force billing parameters on the server side.
さまざまなビジネスモデル（この提案の範囲外）が達成される可能性があります。品質セッションの支払い者に応じて、サーバーは最初のメッセージで送信された特定のクライアントパラメーターを受け入れるか、サーバー側で課金パラメーターを強制できます。
Different client and server implementations may send a different number of PING messages for measuring, although at least 255 messages should be considered to perform the latency measurement. The Stage 0 measurements may be considered ended only when neither the client nor server receive new PING messages after an implementation-dependent guard time. Only after, the client can send a "READY 1" message.
レイテンシ測定を実行するには少なくとも255メッセージを考慮する必要がありますが、クライアントとサーバーの実装が異なると、測定するPINGメッセージの数も異なります。ステージ0の測定は、実装に依存するガードタイムの後でクライアントもサーバーも新しいPINGメッセージを受信しない場合にのみ終了したと見なされます。その後、クライアントは「READY 1」メッセージを送信できます。
In execution systems, where the timers are not accurate, a recommended approach consists of including the optional Timestamp header field in the PING request with the time in which the message has been sent. This allows an accurate measurement of the jitter even with no identical intervals of time between PINGs.
タイマーが正確でない実行システムでは、推奨されるアプローチは、メッセージが送信された時間とともにPING要求にオプションのTimestampヘッダーフィールドを含めることから成ります。これにより、PING間の時間間隔が同じでなくても、ジッタを正確に測定できます。
In programming languages or operating systems with limited timers or clock resolution, it is recommended to use an approach based on several intervals to send messages of 1KB (= 8000 bits) in order to reach the required bandwidth consumption, using a rate as close as possible to a constant rate.
プログラミング言語またはオペレーティングシステムでタイマーまたはクロック解像度が制限されている場合、必要な帯域幅の消費量にできるだけ近いレートを使用して、1KB（= 8000ビット）のメッセージを送信するために、いくつかの間隔に基づくアプローチを使用することをお勧めします一定のレートに。
For example, if the resolution is 1 millisecond, and the bandwidth to reach is 11 Mbps, a good approach consists of sending:
たとえば、解像度が1ミリ秒であり、到達する帯域幅が11 Mbpsの場合、適切なアプローチは送信で構成されます。
1 message of 1KB every 1 millisecond +
1ミリ秒ごとに1 KBのメッセージ1つ+
1 message of 1KB every 3 milliseconds +
3ミリ秒ごとに1 KBのメッセージ1つ+
1 message of 1KB every 23 milliseconds
23ミリ秒ごとに1KBのメッセージが1つ
The number of intervals depends on the required bandwidth and accuracy that the programmer wants to achieve.
間隔の数は、必要な帯域幅とプログラマーが達成したい精度によって異なります。
Considering messages of 1KB (= 8000 bits), a general approach to determine these intervals is the following:
1KB（= 8000ビット）のメッセージを考えると、これらの間隔を決定する一般的なアプローチは次のとおりです。
(1) Compute target bandwidth / 8000 bits. In the example above, it is 11 Mbps / 8000 = 1375 messages per second.
（1）計算対象帯域幅/ 8000ビット。上記の例では、11 Mbps / 8000 = 1375メッセージ/秒です。
(2) Divide the number of messages per second by 1000 to determine the number of messages per millisecond: 1375 / 1000 = 1.375. The integer value is the number of messages per millisecond (in this case, one). The pending bandwidth is now 375 messages per second.
（2）1秒あたりのメッセージ数を1000で割り、1ミリ秒あたりのメッセージ数を決定します。1375/ 1000 = 1.375。整数値は、ミリ秒あたりのメッセージ数（この場合は1）です。保留中の帯域幅は現在、毎秒375メッセージです。
(3) To achieve the 375 messages per second, use a submultiple of 1000, which must be less than 375:
（3）1秒あたり375メッセージを実現するには、1000の約数を使用します。これは375未満でなければなりません。
1000 / 2 = 500 > 375
1000 / 3 = 333 < 375
In this case, a message every 3 ms is suitable. The new pending target bandwidth is 375 - 333 = 42 messages per second.
この場合、3 msごとのメッセージが適しています。新しい保留中のターゲット帯域幅は、375-333 = 1秒あたり42メッセージです。
(4) Repeat the same strategy as point 3 to reach the pending bandwidth. In this case, 23 ms is suitable because of the following:
（4）ポイント3と同じ戦略を繰り返して、保留中の帯域幅に到達します。この場合、次の理由により23ミリ秒が適切です。
1000 / 22 = 45 > 42
1000 / 23 = 43 > 42
1000 / 24 = 41.6 < 42
We can choose 24 ms, but then we need to cover an additional 0.4 messages per second (42 - 41.6 = 0.4), and 43 is a number higher than 42 but very close to it.
24ミリ秒を選択できますが、毎秒追加の0.4メッセージ（42-41.6 = 0.4）をカバーする必要があり、43は42より大きい数値ですが、それに非常に近い数値です。
In execution systems where the timers are not accurate, a recommended approach consists of checking at each interval the number of packets that should have been sent at this timestamp since origin and send the needed number of packets in order to reach the required bandwidth.
タイマーが正確ではない実行システムでは、推奨されるアプローチは、発信元からこのタイムスタンプで送信されたはずのパケット数を各間隔でチェックし、必要な帯域幅に到達するために必要な数のパケットを送信することです。
The shorter the packets used, the more constant the rate of bandwidth measurement. However, this may stress the execution system in charge of receiving and processing packets. As a consequence, some packets may be lost because of stack overflows. To deal with this potential issue, a larger packet is RECOMMENDED (2KB or more), taking into account the overhead produced by the chunks' headers.
使用するパケットが短いほど、帯域幅測定の速度は一定になります。ただし、これにより、パケットの受信と処理を担当する実行システムに負荷がかかる可能性があります。その結果、スタックオーバーフローが原因で一部のパケットが失われる可能性があります。この潜在的な問題に対処するには、チャンクのヘッダーによって生じるオーバーヘッドを考慮して、より大きなパケットを推奨します（2KB以上）。
Depending on the application nature and network conditions, a packet loss resolution less than 1% may be needed. In such cases, there is no limit to the number of samples used for this calculation. A trade-off between time and resolution should be reached in each case. For example, in order to have a resolution of 1/10000, the last 10000 samples should be considered in the packet loss measured value.
アプリケーションの性質とネットワークの状態によっては、1％未満のパケット損失解決が必要になる場合があります。このような場合、この計算に使用されるサンプルの数に制限はありません。いずれの場合も、時間と解像度の間のトレードオフに達する必要があります。たとえば、分解能を1/10000にするには、最後の10000サンプルをパケット損失測定値で考慮する必要があります。
The problem of this approach is the reliability of old samples. If the interval used between PING messages is 50 ms, then to have a resolution of 1/1000, it takes 50 seconds, and a resolution of 1/10000 takes 500 seconds (more than 8 minutes). The reliability of a packet loss calculation based on a sliding window of 8 minutes depends on how fast network conditions evolve.
このアプローチの問題は、古いサンプルの信頼性です。 PINGメッセージの間隔が50ミリ秒の場合、1/1000の解像度を得るには50秒かかり、1/10000の解像度には500秒（8分以上）かかります。 8分のスライディングウィンドウに基づくパケット損失計算の信頼性は、ネットワーク状態の変化の速さに依存します。
Q4S can be used as a mechanism to measure and trigger network tuning and application-level actions (i.e. lowering video bit-rate, reducing multiplayer interaction speed, etc.) in real time in order to reach the application constraints, addressing measured possible network degradation.
Q4Sは、ネットワークのチューニングとアプリケーションレベルのアクション（ビデオのビットレートの低下、マルチプレーヤーの対話速度の低下など）をリアルタイムで測定およびトリガーするメカニズムとして使用でき、アプリケーションの制約に到達して、測定されたネットワーク劣化の可能性に対処します。
There are two scenarios in which Q4S can be affected by network problems: loss of Q4S packets and outlier samples.
Q4Sがネットワークの問題の影響を受ける可能性のあるシナリオには、Q4Sパケットの損失と外れ値のサンプルの2つがあります。
Lost UDP packets (PING or BWIDTH messages) don't cause any problems for the Q4S state machine, but if TCP packets are delivered too late (which we will consider as "lost"), some undesirable consequences could arise.
失われたUDPパケット（PINGまたはBWIDTHメッセージ）はQ4Sステートマシンに問題を引き起こしませんが、TCPパケットの配信が遅すぎる（「失われた」と見なします）場合、望ましくない結果が発生する可能性があります。
Q4S does have protection mechanisms to overcome these situations. Examples:
Q4Sには、これらの状況を克服する保護メカニズムがあります。例：
* If a BEGIN packet or its corresponding answer is lost, after a certain timeout, the client SHOULD resend another BEGIN packet, resetting the session
* BEGINパケットまたはそれに対応する応答が失われた場合、一定のタイムアウトの後、クライアントはセッションをリセットして、別のBEGINパケットを再送信する必要があります（SHOULD）。
* If a READY packet is lost, after a certain timeout, the client SHOULD resend another READY packet.
* READYパケットが失われた場合、一定のタイムアウトの後、クライアントは別のREADYパケットを再送信する必要があります（SHOULD）。
* If a Q4S-ALERT request or its corresponding answer is lost, after a certain timeout, the originator SHOULD resend another Q4S-ALERT packet.
* Q4S-ALERT要求またはそれに対応する応答が失われた場合、一定のタイムアウトの後、発信者は別のQ4S-ALERTパケットを再送信する必要があります（SHOULD）。
* If a CANCEL request or its corresponding answer is lost, after a certain timeout, the originator SHOULD resend another CANCEL packet.
* CANCEL要求またはそれに対応する応答が失われた場合、一定のタイムアウトの後、発信者は別のCANCELパケットを再送信する必要があります（SHOULD）。
Outlier samples are those jitter or latency values far from the general/average values of most samples.
外れ値のサンプルは、ほとんどのサンプルの一般的な値/平均値から離れたジッターまたはレイテンシの値です。
Hence, the Q4S default measurement method uses the statistical median formula for latency calculation, and the outlier samples are neutralized. This is a very common filter for noise or errors on signal and image processing.
したがって、Q4Sのデフォルトの測定方法では、レイテンシの計算に統計中央値の式を使用し、外れ値のサンプルは無効化されます。これは、信号や画像処理でのノイズやエラーの非常に一般的なフィルターです。
Q4S could be used in two scenarios:
Q4Sは次の2つのシナリオで使用できます。
* client to ACP
* クライアントからACP
* client to client (peer-to-peer scenario)
* クライアント間（ピアツーピアシナリオ）
One server:
1つのサーバー：
It is the common scenario in which the client contacts the server to establish a Q4S session.
これは、クライアントがサーバーに接続してQ4Sセッションを確立する一般的なシナリオです。
N servers:
Nサーバー：
In Content Delivery Networks and in general applications where delivery of contents can be achieved by different delivery nodes, two working mechanisms can be defined:
コンテンツ配信ネットワークや、さまざまな配信ノードでコンテンツの配信を実現できる一般的なアプリケーションでは、2つの動作メカニズムを定義できます。
Starting mode: the end user may run Q4S against several delivery nodes and after some seconds choose the best one to start the multimedia session.
開始モード：エンドユーザーは複数の配信ノードに対してQ4Sを実行し、数秒後にマルチメディアセッションを開始するのに最適なノードを選択できます。
Prevention mode: during a streaming session, the user keeps several Q4S dialogs against different alternative delivery nodes. In case of congestion, the end user MAY change to the best alternative delivery node.
防止モード：ストリーミングセッション中、ユーザーはさまざまな代替配信ノードに対していくつかのQ4Sダイアログを保持します。輻輳が発生した場合、エンドユーザーは最適な代替配信ノードに変更できます（MAY）。
In order to solve the client-to-client scenario, a Q4S register function MUST be implemented. This allows clients to contact each other for sending the BEGIN message. In this scenario, the Register server would be used by peers to publish their Q4S-Resource-Server header and their public IP address to enable the assumption of the server role.
クライアントからクライアントへのシナリオを解決するには、Q4S登録関数を実装する必要があります。これにより、クライアントは相互に連絡してBEGINメッセージを送信できます。このシナリオでは、ピアがRegisterサーバーを使用して、Q4S-Resource-ServerヘッダーとパブリックIPアドレスを公開し、サーバーの役割を引き受けます。
The register function is out of scope of this protocol version because different HTTP mechanisms can be used, and Q4S MUST NOT force any.
異なるHTTPメカニズムを使用できるため、登録機能はこのプロトコルバージョンの範囲外であり、Q4Sは強制しないでください。
Because Q4S does not transport any application data, Q4S does not jeopardize the security of application data. However, other certain considerations may take place, like identity impersonation and measurements privacy and integrity.
Q4Sはアプリケーションデータを転送しないため、Q4Sはアプリケーションデータのセキュリティを危険にさらしません。ただし、IDのなりすましやプライバシーと整合性の測定など、他の特定の考慮事項が発生する場合があります。
Identity impersonation could potentially produce anomalous Q4S measurements. If this attack is based on spoofing of the server IP address, it can be avoided using the digital signature mechanism included in the SDP. The network can easily validate this digital signature using the public key of the server certificate.
IDの偽装により、異常なQ4S測定値が生成される可能性があります。この攻撃がサーバーIPアドレスのスプーフィングに基づいている場合は、SDPに含まれているデジタル署名メカニズムを使用して回避できます。ネットワークは、サーバー証明書の公開鍵を使用して、このデジタル署名を簡単に検証できます。
Integrity of Q4S measurements under any malicious manipulation (such as a Man-in-the-Middle (MITM) attack) relies on the same mechanism, the SDP signature.
悪意のある操作（中間者（MITM）攻撃など）の下でのQ4S測定の整合性は、同じメカニズムであるSDPシグネチャに依存しています。
The Signature header field contains the signed hash value of the SDP body in order to protect all the SDP data, including the measurements. This signature not only protects the integrity of data but also authenticates the server.
測定を含むすべてのSDPデータを保護するために、SignatureヘッダーフィールドにはSDP本体の署名付きハッシュ値が含まれています。この署名は、データの整合性を保護するだけでなく、サーバーを認証します。
This protocol could be supported over IPsec. Q4S relies on UDP and TCP, and IPsec supports both. If Q4S is used for application-based QoS, then IPsec is operationally valid; however, if Q4S is used to trigger network-based actions, then measurements could be incorrect unless the IPsec ports can be a target of potential action over the network (such as prioritizing IPsec flows to measure the new, upgraded state of certain application flows).
このプロトコルは、IPsecでサポートできます。 Q4SはUDPとTCPに依存しており、IPsecは両方をサポートしています。 Q4SがアプリケーションベースのQoSに使用されている場合、IPsecは運用上有効です。ただし、Q4Sを使用してネットワークベースのアクションをトリガーする場合、IPsecポートがネットワーク上の潜在的なアクションのターゲットになり得ない場合（IPsecフローに優先順位を付けて、特定のアプリケーションフローの新しくアップグレードされた状態を測定するなど）でない限り、測定は正しくない可能性があります。 。
Any loss of connectivity may interrupt the availability of the Q4S service and may result in higher packet loss measurements, which is just the desired behavior in these situations.
接続が失われると、Q4Sサービスの可用性が妨げられ、パケット損失の測定値が高くなることがあります。これは、これらの状況での望ましい動作です。
In order to mitigate availability issues caused by malicious attacks (such as DoS and DDoS), a good practice is to enable the Q4S service only for authenticated users. Q4S can be launched after the user is authenticated by the application. At this moment, the user's IP address is known, and the Q4S service may be enabled for this IP address. Otherwise, the Q4S service should appear unreachable.
悪意のある攻撃（DoSやDDoSなど）によって引き起こされる可用性の問題を軽減するには、認証されたユーザーに対してのみQ4Sサービスを有効にすることをお勧めします。 Q4Sは、ユーザーがアプリケーションによって認証された後に起動できます。この時点で、ユーザーのIPアドレスは既知であり、Q4SサービスはこのIPアドレスに対して有効になっている可能性があります。それ以外の場合、Q4Sサービスは到達不能に見えるはずです。
Q4S bandwidth measurement is limited to the application needs. It means that all available bandwidth is not measured, but only the fraction required by the application. This allows other applications to use the rest of available bandwidth normally.
Q4S帯域幅測定は、アプリケーションのニーズに限定されます。つまり、すべての利用可能な帯域幅が測定されるのではなく、アプリケーションが必要とする部分だけが測定されます。これにより、他のアプリケーションは残りの使用可能な帯域幅を通常どおりに使用できます。
However, a malicious Q4S client could restart Q4S sessions just after finishing the Negotiation phase. The consequence would be to waste bandwidth for nothing.
ただし、悪意のあるQ4Sクライアントは、交渉フェーズの終了直後にQ4Sセッションを再開する可能性があります。その結果、帯域幅が無駄に浪費されることになります。
In order to mitigate this possible anomalous behavior, it is RECOMMENDED to configure the server to reject sessions from the same endpoint when this situation is detected.
この起こり得る異常な動作を軽減するために、この状況が検出されたときに同じエンドポイントからのセッションを拒否するようにサーバーを構成することをお勧めします。
If the ideas described in this document are pursued to become a protocol specification, then the code points described in this document will need to be assigned by IANA.
このドキュメントで説明されているアイデアがプロトコル仕様になるように追求されている場合、このドキュメントで説明されているコードポイントはIANAによって割り当てられる必要があります。
An assigned port would make possible a future Q4S-aware network capable of reacting by itself to Q4S alerts. A specific port would simplify the identification of the protocol by network elements in charge of making possible reactive decisions. Therefore, the need for a port assignment by IANA may be postponed until there is the need for a future Q4S-aware network.
割り当てられたポートにより、Q4Sアラートに単独で対応できる将来のQ4S対応ネットワークが可能になります。特定のポートは、可能な反応的な決定を行うことを担当するネットワーク要素によるプロトコルの識別を簡素化します。したがって、IANAによるポート割り当ての必要性は、将来のQ4S対応ネットワークが必要になるまで延期される可能性があります。
Service Name: Q4S
サービス名：Q4S
Transport Protocol(s): TCP
Assignee: Name: Jose Javier Garcia Aranda
担当者：名前：ホセハビエルガルシアアランダ
Email: jose_javier.garcia_aranda@nokia.com
Contact: Name: Jose Javier Garcia Aranda
連絡先：名前：Jose Javier Garcia Aranda
Email: jose_javier.garcia_aranda@nokia.com
Description: The service associated with this request is in charge of the establishment of new Q4S sessions, and during the session, manages the handoff to a new protocol phase (Handshake, Negotiation and Continuity) as well as sends alerts when measurements do not meet the requirements.
説明：このリクエストに関連付けられたサービスは、新しいQ4Sセッションの確立を担当し、セッション中に、新しいプロトコルフェーズ（ハンドシェイク、ネゴシエーション、および継続性）へのハンドオフを管理し、測定値が要件。
Reference: This document. This service does not use IP-layer broadcast, multicast, or anycast communication.
参照：このドキュメント。このサービスは、IPレイヤーのブロードキャスト、マルチキャスト、またはエニーキャスト通信を使用しません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<https://www.rfc-editor.org/info/rfc7232> 。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7233] Fielding、R.、Ed。、Lafon、Y.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Range Requests"、RFC 7233、DOI 10.17487 / RFC7233、June 2014、<https://www.rfc-editor.org/info/rfc7233>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<https://www.rfc-editor.org/info/rfc7235>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5322>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：//www.rfc- editor.org/info/rfc6234>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS＃1：RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org / info / rfc3264>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-29, 9 June 2020, <https://tools.ietf.org/html/draft-ietf-quic-transport-29>.
[QUIC] Iyengar、J。およびM. Thomson、「QUIC：UDPベースの多重化された安全なトランスポート」、進行中の作業、インターネットドラフト、draft-ietf-quic-transport-29、2020年6月9日、<https： //tools.ietf.org/html/draft-ietf-quic-transport-29>。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006、<https://www.rfc-editor.org/info/rfc4656>。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008、<https://www.rfc-editor.org/info/rfc5357>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RENO] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", ACM SIGCOMM Computer Communication Review, pp. 67-82, DOI 10.1145/263932.264023, July 1997, <https://doi.org/10.1145/263932.264023>.
[RENO] Mathis、M.、Semke、J.、Madhavi、J。、およびT. Ott、「TCP輻輳回避アルゴリズムの巨視的な動作」、ACM SIGCOMMコンピュータ通信レビュー、67-82ページ、DOI 10.1145 / 263932.264023、1997年7月、<https://doi.org/10.1145/263932.264023>。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, <https://www.rfc-editor.org/info/rfc3649>.
[RFC3649] Floyd、S。、「大規模な輻輳ウィンドウ用のHighSpeed TCP」、RFC 3649、DOI 10.17487 / RFC3649、2003年12月、<https://www.rfc-editor.org/info/rfc3649>。
[CUBIC] Rhee, I., Xu, L., and S. Ha, "CUBIC for Fast Long-Distance Networks", Work in Progress, Internet-Draft, draft-rhee-tcpm-cubic-02, 26 August 2008, <https://tools.ietf.org/html/draft-rhee-tcpm-cubic-02>.
[CUBIC] Rhee、I.、Xu、L。、およびS. Ha、「高速長距離ネットワークのCUBIC」、作業中、インターネットドラフト、draft-rhee-tcpm-cubic-02、2008年8月26日、 <https://tools.ietf.org/html/draft-rhee-tcpm-cubic-02>。
[CTCP] Sridharan, M., Tan, K., Bansal, D., and D. Thaler, "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", Work in Progress, Internet-Draft, draft-sridharan-tcpm-ctcp-02, 11 November 2008, <https://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02>.
[CTCP] Sridharan、M.、Tan、K.、Bansal、D。、およびD. Thaler、「Compound TCP：A New TCP Congestion Control for High-Speed and Long Distance Networks」、Work in Progress、Internet-Draft、 draft-sridharan-tcpm-ctcp-02、2008年11月11日、<https://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02>。
Acknowledgements
謝辞
Many people have made comments and suggestions contributing to this document. In particular, we would like to thank:
多くの人々がこのドキュメントに貢献するコメントと提案をしました。特に、感謝したいと思います。
Victor Villagra, Sonia Herranz, Clara Cubillo Pastor, Francisco Duran Pina, Michael Scharf, Jesus Soto Viso, and Federico Guillen.
ビクターヴィラグラ、ソニアヘランツ、クララクビロ牧師、フランシスコデュランピナ、マイケルシャーフ、ジーザスソトヴィソ、フェデリコギレン。
Additionally, we want to thank the Spanish Centre for the Development of Industrial Technology (CDTI) as well as the Spanish Science and Tech Ministry, which funds this initiative through their innovation programs.
さらに、スペイン産業技術開発センター（CDTI）と、イノベーションプログラムを通じてこのイニシアチブに資金を提供しているスペイン科学技術省に感謝します。
Contributors
貢献者
Jacobo Perez Lajo Nokia Spain
ジャコボペレスラホノキアスペイン
Email: jacobo.perez@nokia.com
Luis Miguel Diaz Vizcaino Nokia Spain
ルイスミゲルディアスビスカイーノノキアスペイン
Email: Luismi.Diaz@nokia.com
Gonzalo Munoz Fernandez Nokia Spain
ゴンサロムニョスフェルナンデスノキアスペイン
Email: gonzalo.munoz_fernandez.ext@nokia.com
Manuel Alarcon Granero Nokia Spain
マヌエルアラルコングラネロノキアスペイン
Email: manuel.alarcon_granero.ext@nokia.com
Francisco Jose Juan Quintanilla Nokia Spain
フランシスコホセフアンキンタニージャノキアスペイン
Email: francisco_jose.juan_quintanilla.ext@nokia.com
Carlos Barcenilla Universidad Politecnica de Madrid
マドリードのカルロスバルセニーリャ工科大学
Juan Quemada Universidad Politecnica de Madrid
マドリードのファンケマダ工科大学
Email: jquemada@dit.upm.es
Ignacio Maestro Tecnalia Research & Innovation
イグナシオマエストロテクナリアリサーチ＆イノベーション
Email: ignacio.maestro@tecnalia.com
Lara Fajardo Ibañez Optiva Media
ララファハルドイバニェスオプティバメディア
Email: lara.fajardo@optivamedia.com
Pablo López Zapico Optiva Media
パブロロペスザピコオプティバメディア
Email: Pablo.lopez@optivamedia.com
David Muelas Recuenco Universidad Autonoma de Madrid
マドリッドのデビッドムエラスレクエンコ自治大学
Email: dav.muelas@uam.es
Jesus Molina Merchan Universidad Autonoma de Madrid
ジーザスモリナメルチャンマドリード自治大学
Email: jesus.molina@uam.es
Jorge E. Lopez de Vergara Mendez Universidad Autonoma de Madrid
ホルヘEロペスデベルガラメンデスマドリード自治大学
Email: jorge.lopez_vergara@uam.es
Victor Manuel Maroto Ortega Optiva Media
ビクターマヌエルマロトオルテガオプティバメディア
Email: victor.maroto@optivamedia.com
Authors' Addresses
著者のアドレス
Jose Javier Garcia Aranda Nokia María Tubau 9 28050 Madrid Spain
ホセハビエルガルシアアランダノキアマリアトゥバウ9 28050マドリードスペイン
Phone: +34 91 330 4348
Email: jose_javier.garcia_aranda@nokia.com
Mónica Cortés Nokia María Tubau 9 28050 Madrid Spain
MónicaCortésNokiaMaríaTubau 9 28050マドリードスペイン
Email: monica.cortes_sack@nokia.com
Joaquín Salvachúa Universidad Politecnica de Madrid Avenida Complutense 30 28040 Madrid Spain
ホアキンサルバチュアポリテクニック大学マドリードアベニーダコンプルテンセ30 28040マドリードスペイン
Phone: +34 91 0672134
Email: Joaquin.salvachua@upm.es
Maribel Narganes Tecnalia Research & Innovation Parque Científico y Tecnológico de Bizkaia Astondo Bidea, Edificio 700 E-48160 Derio Bizkaia Spain
Maribel Narganes Tecnalia Research＆Innovation Bizkaia Science and Technology Park Astondo Bidea、Building 700 E-48160 Derio Bizkaia Spain
Phone: +34 946 430 850
Email: maribel.narganes@tecnalia.com
Iñaki Martínez-Sarriegui Optiva Media Edificio Europa II, Calle Musgo 2, 1G, 28023 Madrid Spain
IñakiMartínez-SarrieguiOptiva Media Edificio Europa II、Calle Mosgo 2、1G、28023マドリードスペイン
Phone: +34 91 297 7271
Email: inaki.martinez@optivamedia.com