[要約] RFC 8837は、WebRTC (Web Real-Time Communication) アプリケーションの品質保証(QoS: Quality of Service)を向上させるために、Differentiated Services Code Point (DSCP) パケットマーキングを使用する方法について説明しています。この文書の目的は、WebRTCのトラフィックをネットワーク上で適切に識別し、優先順位付けすることにより、リアルタイム通信の品質を保証することです。利用場面としては、ビデオ会議、オンラインゲーム、リアルタイムのデータストリーミングなど、遅延に敏感なアプリケーションがあります。関連するRFCには、RFC 2474（Differentiated Services (DiffServ) アーキテクチャの定義）やRFC 7657（DiffServにおけるトラフィック分類と管理のガイドライン）などがあります。
Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 8837 Cisco Systems
Category: Standards Track S. Dhesikan
ISSN: 2070-1721 Individual
C. Jennings
Cisco Systems
D. Druta
AT&T
January 2021
Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS
WebRTC QoSの差別化サービスコードポイント（DSCP）パケットマーキング
Abstract
概要
Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-Time Communication (WebRTC) traffic.
ネットワークは、区別されたサービスコードポイント（DSCP）値に基づいて、ホップごとの個々のパケットに対して異なる転送処理を提供できます。このドキュメントでは、Webブラウザの推奨されるDSCP値がWebリアルタイム通信（WEBRTC）トラフィックのさまざまなクラスに使用するための推奨されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8837.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8837で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Relation to Other Specifications
4. Inputs
5. DSCP Mappings
6. Security Considerations
7. IANA Considerations
8. Downward References
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Dedication
Authors' Addresses
Differentiated Services Code Point (DSCP) [RFC2474] packet marking can help provide QoS in some environments. This specification provides default packet marking for browsers that support WebRTC applications, but does not change any advice or requirements in other RFCs. The contents of this specification are intended to be a simple set of implementation recommendations based on previous RFCs.
差別化サービスコードポイント（DSCP）[RFC2474]パケットマーキングは、一部の環境でQoSを提供するのに役立ちます。この仕様は、WebRTCアプリケーションをサポートするブラウザのデフォルトのパケットマーキングを提供しますが、他のRFCのアドバイスや要件は変更されません。この仕様の内容は、以前のRFCに基づく一連の実装推奨事項のセットであることを目的としています。
Networks in which these DSCP markings are beneficial (likely to improve QoS for WebRTC traffic) include:
これらのDSCPマーキングが有益なネットワーク（WebRTCトラフィックのQoSを改善する可能性が高い）には、次のものが含まれます。
1. Private, wide-area networks. Network administrators have control over remarking packets and treatment of packets.
1. プライベート、広域ネットワーク。ネットワーク管理者は、パケットのパケットとパケットの処理を制御しています。
2. Residential Networks. If the congested link is the broadband uplink in a cable or DSL scenario, residential routers/NAT often support preferential treatment based on DSCP.
2. 住宅ネットワーク混雑したリンクがケーブルまたはDSLシナリオのブロードバンドアップリンクである場合、住宅ルーター/ NATはしばしばDSCPに基づく優先扱いをサポートします。
3. Wireless Networks. If the congested link is a local wireless network, marking may help.
3. ワイヤレスネットワーク。輻輳リンクがローカルの無線ネットワークの場合、マーキングは役に立ちます。
There are cases where these DSCP markings do not help but, aside from possible priority inversion for "Less-than-Best-Effort traffic" (see Section 5), they seldom make things worse if packets are marked appropriately.
これらのDSCPマーキングが役立っていない場合がありますが、「ベスト化されていないトラフィック」のための可能な優先順位の反転（セクション5を参照）を除いて、パケットが適切にマークされている場合はほとんど悪くなりません。
DSCP values are, in principle, site specific with each site selecting its own code points for controlling per-hop behavior to influence the QoS for transport-layer flows. However, in the WebRTC use cases, the browsers need to set them to something when there is no site-specific information. This document describes a subset of DSCP code point values drawn from existing RFCs and common usage for use with WebRTC applications. These code points are intended to be the default values used by a WebRTC application. While other values could be used, using a non-default value may result in unexpected per-hop behavior. It is RECOMMENDED that WebRTC applications use non-default values only in private networks that are configured to use different values.
DSCP値は、原則として、各サイトで特定のサイトが特定のサイト固有のサイトが、トランスポート層の流れのためのQoSに影響を与えるためのそれ自身のコードポイントを選択します。ただし、WEBRTCユースケースでは、サイト固有の情報がない場合、ブラウザはそれらを何かに設定する必要があります。このドキュメントでは、既存のRFCから描かれたDSCPコードポイント値のサブセットと、WEBRTCアプリケーションで使用するための一般的な使用法について説明します。これらのコードポイントは、WebRTCアプリケーションで使用されるデフォルト値であることを目的としています。他の値を使用できるが、デフォルト以外の値を使用すると、予期せぬホップごとの動作が発生する可能性があります。WebRTCアプリケーションは、異なる値を使用するように構成されているプライベートネットワークでのみ、デフォルト以外の値を使用することをお勧めします。
This specification defines inputs that are provided by the WebRTC application hosted in the browser that aid the browser in determining how to set the various packet markings. The specification also defines the mapping from abstract QoS policies (flow type, priority level) to those packet markings.
この仕様は、ブラウザでホストされているWebRTCアプリケーションによって提供される入力を定義し、ブラウザがさまざまなパケットマーキングの設定方法を決定する方法を決定します。仕様は、抽象QoSポリシー（フロータイプ、優先順位レベル）からそれらのパケットマーキングへのマッピングも定義されます。
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.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
The terms "browser" and "non-browser" are defined in [RFC7742] and carry the same meaning in this document.
「ブラウザ」と「ブラウザ以外の」という用語は、[RFC7742]で定義され、この文書で同じ意味を持ちます。
This document is a complement to [RFC7657], which describes the interaction between DSCP and real-time communications. That RFC covers the implications of using various DSCP values, particularly focusing on the Real-time Transport Protocol (RTP) [RFC3550] streams that are multiplexed onto a single transport-layer flow.
この文書は[RFC7657]を補完するもので、DSCPとリアルタイム通信との間の相互作用を説明します。そのRFCは、単一のトランスポート層の流れに多重化されているリアルタイムトランスポートプロトコル（RFC3550]ストリームに特に焦点を当てて、さまざまなDSCP値を使用するという意味を網羅しています。
There are a number of guidelines specified in [RFC7657] that apply to marking traffic sent by WebRTC applications, as it is common for multiple RTP streams to be multiplexed on the same transport-layer flow. Generally, the RTP streams would be marked with a value as appropriate from Table 1. A WebRTC application might also multiplex data channel [RFC8831] traffic over the same 5-tuple as RTP streams, which would also be marked per that table. The guidance in [RFC7657] says that all data channel traffic would be marked with a single value that is typically different from the value(s) used for RTP streams multiplexed with the data channel traffic over the same 5-tuple, assuming RTP streams are marked with a value other than Default Forwarding (DF). This is expanded upon further in the next section.
WEBRTCアプリケーションによって送信されたマーキングトラフィックに適用される[RFC7657]で指定されたガイドラインは、同じトランスポート層の流れで多重化されるのが一般的です。一般的に、RTPストリームは表1から適切な値でマークされます。WebRTCアプリケーションは、RTPストリームと同じ5タプルでデータチャネル[RFC8831]トラフィックをマルチプレックスすることもできます。これはその表にマークされます。[RFC7657]のガイダンスは、RTPストリームを仮定して、同じ5タプルでデータチャネルトラフィックと多重化されたRTPストリームで使用されるRTPストリームで使用される値とは異なる単一の値でマークされていると述べています。デフォルトの転送（DF）以外の値でマークされています。これは次のセクションでさらに展開されます。
This specification does not change or override the advice in any other RFCs about setting packet markings. Rather, it simply selects a subset of DSCP values that is relevant in the WebRTC context.
この仕様は、パケットマーキングの設定に関する他のRFCのアドバイスを変更または上書きしません。むしろ、それは単にWebRTCコンテキストに関連するDSCP値のサブセットを選択するだけです。
The DSCP value set by the endpoint is not trusted by the network. In addition, the DSCP value may be remarked at any place in the network for a variety of reasons to any other DSCP value, including the DF value to provide basic best-effort service. Even so, there is a benefit to marking traffic even if it only benefits the first few hops. The implications are discussed in Section 3.2 of [RFC7657]. Further, a mitigation for such action is through an authorization mechanism. Such an authorization mechanism is outside the scope of this document.
エンドポイントによって設定されたDSCP値は、ネットワークによって信頼されていません。さらに、基本的なベストエフォートサービスを提供するためのDF値を含む、他のDSCP値のさまざまな理由で、DSCP値をネットワーク内のどこにでも述べることができます。それでも、最初の数ホップの利益だけでなく、トラフィックをマーキングすることが恩恵を受けます。その意味は[RFC7657]のセクション3.2で議論されています。さらに、そのような行動の緩和は許可メカニズムを通してである。そのような許可メカニズムはこの文書の範囲外です。
This document recommends DSCP values for two classes of WebRTC flows:
このドキュメントでは、2つのクラスのWebRTCフローに対するDSCP値をお勧めします。
* media flows that are RTP streams [RFC8834]
* RTPストリームであるメディアフロー[RFC8834]
* data flows that are data channels [RFC8831]
* データチャネルであるデータフロー[RFC8831]
Each of the RTP streams and distinct data channels consist of all of the packets associated with an independent media entity, so an RTP stream or distinct data channel is not always equivalent to a transport-layer flow defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). There may be multiple RTP streams and data channels multiplexed over the same 5-tuple, with each having a different level of importance to the application and, therefore, potentially marked using different DSCP values than another RTP stream or data channel within the same transport-layer flow. (Note that there are restrictions with respect to marking different data channels carried within the same Stream Control Transmission Protocol (SCTP) association as outlined in Section 5.)
RTPストリームおよび異なるデータチャネルの各々は、独立したメディアエンティティに関連するすべてのパケットで構成されているので、RTPストリームまたは異なるデータチャネルは、5タプルで定義されたトランスポート層の流れと常に同等ではありません（ソースアドレス、宛先アドレス、送信元ポート、宛先ポート、およびプロトコル）。複数のRTPストリームとデータチャネルが同じ5タプルで多重化され、それぞれがアプリケーションとは異なるレベルの重要度を持ち、したがって、同じトランスポート内の別のRTPストリームまたはデータチャネルよりも異なるDSCP値を使用してマークされる可能性がある。レイヤーフロー（セクション5に概説されているように、同じストリーム制御伝送プロトコル（SCTP）の関連付け内に搭載されているさまざまなデータチャネルのマーキングに関する制限があります。）
The following are the inputs provided by the WebRTC application to the browser:
以下は、WebRTCアプリケーションによってブラウザへの入力された入力です。
* Flow Type: The application provides this input because it knows if the flow is audio, interactive video ([RFC4594] [G.1010]) with or without audio, or data.
* フロータイプ：アプリケーションは、音声がオーディオ、またはオーディオの有無にかかわらず、またはデータ、またはデータの有無にかかわらず、この入力を提供します。
* Application Priority: Another input is the relative importance of an RTP stream or data channel. Many applications have multiple flows of the same flow type and some flows are often more important than others. For example, in a video conference where there are usually audio and video flows, the audio flow may be more important than the video flow. JavaScript applications can tell the browser whether a particular flow is of High, Medium, Low, or Very Low importance to the application.
* アプリケーションの優先順位：別の入力は、RTPストリームまたはデータチャネルの相対的な重要性です。多くのアプリケーションは同じフロータイプの複数のフローを持ち、いくつかの流れは他のものよりも多く重要です。例えば、通常はオーディオフローとビデオフローがあるビデオ会議では、オーディオフローはビデオフローよりも重要です。JavaScriptアプリケーションは、特定のフローがアプリケーションに対して高く、中、低、または非常に低いかどうかをブラウザに指示できます。
[RFC8835] defines in more detail what an individual flow is within the WebRTC context and priorities for media and data flows.
[RFC8835]は、個々のフローがWEBRTCのコンテキスト内にあるものと、メディアおよびデータの流れの優先順位の内側にあるものをより詳細に定義します。
Currently in WebRTC, media sent over RTP is assumed to be interactive [RFC8835] and browser APIs do not exist to allow an application to differentiate between interactive and non-interactive video.
現在WebRTCでは、RTPを介して送信されたメディアは対話型[RFC8835]と想定され、ブラウザAPIはアプリケーションが対話式ビデオと非対話型ビデオを区別できるようにするために存在しません。
The DSCP values for each flow type of interest to WebRTC based on application priority are shown in Table 1. These values are based on the framework and recommended values in [RFC4594]. A web browser SHOULD use these values to mark the appropriate media packets. More information on Expedited Forwarding (EF) and Assured Forwarding (AF) can be found in [RFC3246] and [RFC2597], respectively. DF is Default Forwarding, which provides the basic best-effort service [RFC2474].
アプリケーションの優先順位に基づくWebRTCへの関心の各フロータイプのDSCP値を表1に示します。これらの値は、[RFC4594]のフレームワークと推奨値に基づいています。Webブラウザはこれらの値を使用して適切なメディアパケットをマークする必要があります。迅速な転送（EF）および保証された転送（AF）の詳細は、それぞれ[RFC3246]および[RFC2597]にあります。DFはデフォルトの転送です。これは基本的なベストエフォートサービス[RFC2474]を提供します。
WebRTC's use of multiple DSCP values may result in packets with certain DSCP values being blocked by a network. See Section 4.2 of [RFC8835] for further discussion, including how WebRTC implementations establish and maintain connectivity when such blocking is encountered.
WEBRTCの複数のDSCP値の使用は、ネットワークによって特定のDSCP値がブロックされているパケットをもたらす可能性があります。そのようなブロックが発生したときにWebRTC実装がどのように接続されて接続を確立し維持するかを含む、さらなる議論については、[RFC8835]のセクション4.2を参照してください。
+=======================+==========+=====+============+============+
| Flow Type | Very Low | Low | Medium | High |
+=======================+==========+=====+============+============+
| Audio | LE (1) | DF | EF (46) | EF (46) |
| | | (0) | | |
+-----------------------+----------+-----+------------+------------+
+-----------------------+----------+-----+------------+------------+
| Interactive Video | LE (1) | DF | AF42, AF43 | AF41, AF42 |
| with or without Audio | | (0) | (36, 38) | (34, 36) |
+-----------------------+----------+-----+------------+------------+
+-----------------------+----------+-----+------------+------------+
| Non-Interactive Video | LE (1) | DF | AF32, AF33 | AF31, AF32 |
| with or without Audio | | (0) | (28, 30) | (26, 28) |
+-----------------------+----------+-----+------------+------------+
+-----------------------+----------+-----+------------+------------+
| Data | LE (1) | DF | AF11 | AF21 |
| | | (0) | | |
+-----------------------+----------+-----+------------+------------+
Table 1: Recommended DSCP Values for WebRTC Applications
表1：WebRTCアプリケーションの推奨DSCP値
The application priority, indicated by the columns "Very Low", "Low", "Medium", and "High", signifies the relative importance of the flow within the application. It is an input that the browser receives to assist in selecting the DSCP value and adjusting the network transport behavior.
「非常に低い」、「低」、「中」、および「高」の列で示されるアプリケーションの優先順位は、アプリケーション内のフローの相対的な重要性を意味します。ブラウザがDSCP値の選択を支援し、ネットワークトランスポート動作を調整するのに役立つ入力です。
The above table assumes that packets marked with LE are treated as lower effort (i.e., "less than best effort"), such as the LE behavior described in [RFC8622]. However, the treatment of LE is implementation dependent. If an implementation treats LE as other than "less than best effort", then the actual priority (or, more precisely, the per-hop behavior) of the packets may be changed from what is intended. It is common for LE to be treated the same as DF, so applications and browsers using LE cannot assume that LE will be treated differently than DF [RFC7657]. During development of this document, the CS1 DSCP was recommended for "very low" application priority traffic; implementations that followed that recommendation SHOULD be updated to use the LE DSCP instead of the CS1 DSCP.
上記の表は、LEでマークされたパケットが[RFC8622]に記載されているLE動作などのより低い努力（すなわち「最良の努力」よりも小さい）として扱われると仮定している。しかしながら、LEの治療は実施依存的である。実装が「最善よりも少ない努力」以外にLEを扱う場合、パケットの実際の優先順位（またはより正確には、ホップ当たりの動作）は、意図されているものから変更されてもよい。LEはDFと同じように扱われることが一般的であるため、LEを使用したアプリケーションとブラウザは、LEがDF [RFC7657]とは異なる扱いをすると想定できません。この文書の開発中に、CS1 DSCPは「非常に低い」アプリケーション優先順位のトラフィックに推奨されました。推奨事項に従った実装は、CS1 DSCPの代わりにLE DSCPを使用するように更新する必要があります。
Implementers should also note that excess EF traffic is dropped. This could mean that a packet marked as EF may not get through, although the same packet marked with a different DSCP value would have gotten through. This is not a flaw, but how excess EF traffic is intended to be treated.
実装者は、余分なEFトラフィックがドロップされていることも注意してください。これは、異なるDSCP値でマークされているのと同じパケットが到着していたが、EFとしてマークされたパケットが通過しない可能性があることを意味する可能性がある。これは欠陥ではありませんが、余分なEFトラフィックを扱うことを意図している方法です。
The browser SHOULD first select the flow type of the flow. Within the flow type, the relative importance of the flow SHOULD be used to select the appropriate DSCP value.
ブラウザは最初にフローのフロータイプを選択する必要があります。フロータイプ内では、フローの相対的な重要度を使用して適切なDSCP値を選択する必要があります。
Currently, all WebRTC video is assumed to be interactive [RFC8835], for which the interactive video DSCP values in Table 1 SHOULD be used. Browsers MUST NOT use the AF3x DSCP values (for non-interactive video in Table 1) for WebRTC applications. Non-browser implementations of WebRTC MAY use the AF3x DSCP values for video that is known not to be interactive, e.g., all video in a WebRTC video playback application that is not implemented in a browser.
現在、すべてのWebRTCビデオは対話型[RFC8835]で、表1の対話型ビデオDSCP値を使用する必要があります。ブラウザは、WEBRTCアプリケーションのAF3x DSCP値（表1の非対話式ビデオ用）を使用しないでください。WebRTCの非ブラウザの実装は、ブラウザでは実装されていないWebRTCビデオ再生アプリケーション内のすべてのビデオではないことが知られているビデオのAF3X DSCP値を使用することができる。
The combination of flow type and application priority provides specificity and helps in selecting the right DSCP value for the flow. All packets within a flow SHOULD have the same application priority. In some cases, the selected application priority cell may have multiple DSCP values, such as AF41 and AF42. These offer different drop precedences. The different drop precedence values provide additional granularity in classifying packets within a flow. For example, in a video conference, the video flow may have medium application priority, thus either AF42 or AF43 may be selected. More important video packets (e.g., a video picture or frame encoded without any dependency on any prior pictures or frames) might be marked with AF42 and less important packets (e.g., a video picture or frame encoded based on the content of one or more prior pictures or frames) might be marked with AF43 (e.g., receipt of the more important packets enables a video renderer to continue after one or more packets are lost).
フロータイプとアプリケーションの優先順位の組み合わせは、特異性を提供し、フローの右のDSCP値を選択するのに役立ちます。フロー内のすべてのパケットは同じアプリケーションの優先順位を持つ必要があります。場合によっては、選択されたアプリケーション優先セルは、AF41およびAF42などの複数のDSCP値を有することがある。これらは異なるドロップの優先順位を提供します。異なるドロップ優先順位値は、フロー内のパケットの分類において追加の粒度を提供する。例えば、ビデオ会議では、ビデオフローは中程度のアプリケーション優先順位を有することができ、したがってAF42またはAF43のいずれかを選択することができる。より重要なビデオパケット（たとえば、任意の前の写真やフレームに依存することなく符号化されたビデオ画像またはフレーム）は、AF42以前のパケット（例えば、1つまたは複数のコンテンツに基づいて符号化されたフレームなど）でマークされている可能性がある。写真またはフレーム）はAF43でマークされている可能性があります（たとえば、より重要なパケットの受信は、1つ以上のパケットが失われた後にビデオレンダラが続くことができます）。
It is worth noting that the application priority is utilized by the coupled congestion control mechanism for media flows per [RFC8699] and the SCTP scheduler for data channel traffic per [RFC8831].
適用優先順位は、[RFC8699]ごとのメディアフローの結合輻輳制御メカニズムと[RFC8831]のデータチャネルトラフィックのSCTPスケジューラによって利用されることが注目に値します。
For reasons discussed in Section 6 of [RFC7657], if multiple flows are multiplexed using a reliable transport (e.g., TCP), then all of the packets for all flows multiplexed over that transport-layer flow MUST be marked using the same DSCP value. Likewise, all WebRTC data channel packets transmitted over an SCTP association MUST be marked using the same DSCP value, regardless of how many data channels (streams) exist or what kind of traffic is carried over the various SCTP streams. In the event that the browser wishes to change the DSCP value in use for an SCTP association, it MUST reset the SCTP congestion controller after changing values. However, frequent changes in the DSCP value used for an SCTP association are discouraged, as this would defeat any attempts at effectively managing congestion. It should also be noted that any change in DSCP value that results in a reset of the congestion controller puts the SCTP association back into slow start, which may have undesirable effects on application performance.
[RFC7657]のセクション6で説明した理由で、信頼性のあるトランスポート（例えばTCP）を使用して複数のフローが多重化されている場合、そのトランスポート層のフローに対して多重化されたすべてのパケットは同じDSCP値を使用してマークされている必要があります。同様に、SCTPアソシエーションを介して送信されたすべてのWebRTCデータチャネルパケットは、データチャネル（ストリーム）が存在するか、またはさまざまなSCTPストリームを介してどのような種類のトラフィックを伝送するかに関係なく、同じDSCP値を使用してマークされなければなりません。 SCTPアソシエーションに使用されているDSCP値を変更したい場合は、値を変更した後にSCTP輻輳コントローラをリセットする必要があります。ただし、SCTPアソシエーションに使用されるDSCP値の頻繁な変更は、効果的に輻輳を管理する試みを倒すため、推奨されません。また、輻輳コントローラのリセットがリセットされたDSCP値の変更は、SCTPアソシエーションをスロースタートに戻し、アプリケーションのパフォーマンスに望ましくない影響を与える可能性があることにも注意してください。
For the data channel traffic multiplexed over an SCTP association, it is RECOMMENDED that the DSCP value selected be the one associated with the highest priority requested for all data channels multiplexed over the SCTP association. Likewise, when multiplexing multiple flows over a TCP connection, the DSCP value selected SHOULD be the one associated with the highest priority requested for all multiplexed flows.
SCTPアソシエーションを介して多重化されたデータチャネルトラフィックの場合、選択されたDSCP値は、SCTPアソシエーションを介して多重化されたすべてのデータチャネルに対して要求された最高の優先順位に関連付けられていることをお勧めします。同様に、TCP接続を介して複数のフローを多重化するとき、選択されたDSCP値は、すべての多重化フローに対して要求された最高の優先順位に関連するものであるべきです。
If a packet enters a network that has no support for a flow-type-application priority combination specified in Table 1, then the network node at the edge will remark the DSCP value based on policies. This could result in the flow not getting the network treatment it expects based on the original DSCP value in the packet. Subsequently, if the packet enters a network that supports a larger number of these combinations, there may not be sufficient information in the packet to restore the original markings. Mechanisms for restoring such original DSCP is outside the scope of this document.
パケットが表1で指定されたフロータイプアプリケーション優先順位の組み合わせをサポートしていないネットワークに入った場合、エッジのネットワークノードはポリシーに基づいてDSCP値を備えています。これにより、パケット内の元のDSCP値に基づいてネットワーク処理が得られないフローが発生する可能性があります。その後、パケットがこれらの組み合わせの数をサポートするネットワークに入ると、元のマーキングを復元するためのパケット内に十分な情報がないかもしれない。このような元のDSCPを復元するためのメカニズムは、この文書の範囲外です。
In summary, DSCP marking provides neither guarantees nor promised levels of service. However, DSCP marking is expected to provide a statistical improvement in real-time service as a whole. The service provided to a packet is dependent upon the network design along the path, as well as the network conditions at every hop.
要約すると、DSCPマーキングは、保証も約束されたサービスレベルも提供されていません。しかしながら、DSCPマーキングは全体としてリアルタイムサービスの統計的改善を提供すると予想される。パケットに提供されるサービスは、経路に沿ったネットワーク設計、ならびにあらゆるホップのネットワーク状態に依存する。
Since the JavaScript application specifies the flow type and application priority that determine the media flow DSCP values used by the browser, the browser could consider application use of a large number of higher priority flows to be suspicious. If the server hosting the JavaScript application is compromised, many browsers within the network might simultaneously transmit flows with the same DSCP marking. The Diffserv architecture requires ingress traffic conditioning for reasons that include protecting the network from this sort of attack.
JavaScriptアプリケーションは、ブラウザによって使用されるメディアフローDSCP値を決定するフロータイプとアプリケーションの優先順位を指定しているため、ブラウザは疑わしいものになるように多数の優先順位の流れのアプリケーションの使用を検討できます。JavaScriptアプリケーションをホストしているサーバーが侵害されている場合は、ネットワーク内の多くのブラウザが同時に同じDSCPマーキングでフローを送信する可能性があります。DiffServアーキテクチャは、この種の攻撃からネットワークを保護することを含む理由のための入りトラフィック調整を必要とします。
Otherwise, this specification does not add any additional security implications beyond those addressed in the following DSCP-related specifications. For security implications on use of DSCP, please refer to Section 7 of [RFC7657] and Section 6 of [RFC4594]. Please also see [RFC8826] as an additional reference.
それ以外の場合、この仕様は、次のDSCP関連の仕様で対処されているものを超えて追加のセキュリティの影響を追加しません。DSCPの使用に関するセキュリティの影響については、[RFC7657]のセクション7と[RFC4594]のセクション6を参照してください。追加の参照として[RFC8826]も参照してください。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This specification contains downwards references to [RFC4594] and [RFC7657]. However, the parts of the former RFCs used by this specification are sufficiently stable for these downward references. The guidance in the latter RFC is necessary to understand the Diffserv technology used in this document and the motivation for the recommended DSCP values and procedures.
この仕様には、[RFC4594]と[RFC7657]への下位参照が含まれています。しかしながら、本明細書によって使用される前者のRFCの部分は、これらの下方参照に対して十分に安定している。後者のRFCにおけるガイダンスは、この文書で使用されているDiffServ技術と推奨されるDSCP値と手順の動機を理解する必要があります。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<https：//www.rfc-editor.org/ info / rfc4594>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC7657]黒、D.、ED。P. Jones、「差別化サービス（DiffServ）およびリアルタイム通信」、RFC 7657、DOI 10.17487 / RFC 7657、2015年11月、<https：//www.rfc-editor.org/info/rfc7657>。
[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, <https://www.rfc-editor.org/info/rfc7742>.
[RFC7742] ROCH、A.B.、「WEBRTCビデオ処理およびコーデック要件」、RFC 7742、DOI 10.17487 / RFC7742、2016年3月、<https：//www.rfc-editor.org/info/rfc7742>。
[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>。
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[RFC8622] Bless、R.、「差別化サービス用の低稼働単価の行動（LE PHB）」、RFC 8622、DOI 10.17487 / RFC8622、2019年6月、<https：//www.rfc-editor.org/情報/ RFC8622>。
[RFC8826] Rescorla, E., "Security Considerations for WebRTC", RFC 8826, DOI 10.17487/RFC8826, January 2021, <https://www.rfc-editor.org/info/rfc8826>.
[RFC8826] Rescorla、E.、「WebRTCのセキュリティ上の考慮事項」、RFC 8826、DOI 10.17487 / RFC8826、2021年1月、<https：//www.rfc-editor.org/info/rfc8826>。
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.
[RFC8831] Jesup、R.、Loreto、S.、M.Tüxen、「Webrtcデータチャンネル」、RFC 8831、DOI 10.17487 / RFC8831、2021年1月、<https：//www.rfc-editor.org/info/RFC8831>。
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8834] Perkins、C、Westerlund、M.、J. OTT、「WebRTCのメディアトランスポートとRTPの使用」、RFC 8834、DOI 10.17487 / RFC8834、<https：///www.rfc-編集者.ORG / INFO / RFC8834>。
[RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, DOI 10.17487/RFC8835, January 2021, <https://www.rfc-editor.org/info/rfc8835>.
[RFC8835] Alvestrand、H.、「Webrtcの輸送」、RFC 8835、DOI 10.17487 / RFC8835、2021年1月、<https：//www.rfc-editor.org/info/rfc8835>。
[G.1010] ITU-T, "End-user multimedia QoS categories", ITU-T Recommendation G.1010, November 2001, <https://www.itu.int/rec/T-REC-G.1010-200111-I/en>.
[G.1010] ITU-T、「エンドユーザーマルチメディアQoSカテゴリ」、ITU-T勧告G.1010、2001年11月、<https：//www.itu.int/rec/t-rec-g.1010-200111-I / EN>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <https://www.rfc-editor.org/info/rfc2597>.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W.、およびJ.Wroclawski、「保証された転送PHBグループ」、RFC 2597、DOI 10.17487 / RFC2597、1999年6月、<https：///www.rfc-editor.org/info/rfc2597>。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>.
[RFC3246]デイビー、B.、Charny、A。、Bennet、JCR、Benson、K.、Le Boudec、JY、Courtney、W.、Davari、S.、Firoiu、V.、D. Stilidis、「ExpeditedPHBの転送（ホップごとの動作） "、RFC 3246、DOI 10.17487 / RFC3246、2002年3月、<https：//www.rfc-editor.org/info/rfc3246>。
[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：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, January 2020, <https://www.rfc-editor.org/info/rfc8699>.
[RFC8699]イスラム教、S、WELZL、M.およびS.Gjessing、「RTPメディアの結合輻輳制御」、RFC 8699、DOI 10.17487 / RFC8699、2020年1月、<https：//www.rfc-editor.org/ info / rfc8699>。
Acknowledgements
謝辞
Thanks to David Black, Magnus Westerlund, Paolo Severini, Jim Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tüxen, and Brian Carpenter for their invaluable input.
David Black、Magnus Westerlund、Paolo Severini、Jim Hasselbrook、Joe Marcus、Erik Nordmark、MichaelTüxen、Brian Carpenterの貴重な入力に感謝します。
Dedication
献身
This document is dedicated to the memory of James Polk, a long-time friend and colleague. James made important contributions to this specification, including serving initially as one of the primary authors. The IETF global community mourns his loss and he will be missed dearly.
この文書は、長時間の友人と同僚のJames Polkのメモリ専用です。Jamesは、最初に一人称の著者の一人として奉仕するなど、この仕様に重要な貢献をしました。IETFのグローバルコミュニティは彼の損失を悼み、彼は心から逃されるでしょう。
Authors' Addresses
著者の住所
Paul E. Jones Cisco Systems
Paul E. Jones Cisco Systems.
Email: paulej@packetizer.com
Subha Dhesikan Individual
Subha keskan個人
Email: sdhesikan@gmail.com
Cullen Jennings Cisco Systems
Cullen Jennings Cisco Systems.
Email: fluffy@cisco.com
Dan Druta AT&T
Dan Druta at＆T.
Email: dd5826@att.com