[要約] RFC 7657は、Diffservとリアルタイム通信の関係について説明しており、リアルタイム通信の品質を向上させるためのガイドラインを提供しています。目的は、ネットワーク上でのリアルタイム通信のパフォーマンスを最適化することです。
Internet Engineering Task Force (IETF) D. Black, Ed.
Request for Comments: 7657 EMC
Category: Informational P. Jones
ISSN: 2070-1721 Cisco
November 2015
Differentiated Services (Diffserv) and Real-Time Communication
差別化サービス（Diffserv）とリアルタイム通信
Abstract
概要
This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.
このメモは、Differentiated Services（Diffserv）ネットワークのサービス品質（QoS）機能と、リアルタイム転送プロトコル（RTP）に基づく通信を含むリアルタイムネットワーク通信との間の相互作用について説明します。 Diffservは、IPヘッダーが異なるDiffservコードポイント（DSCP）でマークされたパケットに異なる転送処理を適用するネットワークノードに基づいています。 WebRTCアプリケーションと一部の会議アプリケーションは、Session Description Protocol（SDP）バンドルネゴシエーションメカニズムを使用して、同じネットワーク5タプルを使用して、異なるQoS要件を持つ複数のトラフィックストリームを送信し始めました。複数のDSCPを使用して単一のネットワーク5タプル内でさまざまなQoS処理を取得した結果には、特に輻輳制御機能（並べ替えなど）によるトランスポートプロトコルの相互作用があります。さらに、DSCPマーキングは、トラフィックの送信元と宛先の間で変更または削除される場合があります。このメモは、WebRTCを含むリアルタイムネットワーク通信に対するこれらのDiffservアスペクトの影響をカバーしています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7657.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7657で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Real-Time Communications . . . . . . . . . . . . . . . . . . 3
2.1. RTP Background . . . . . . . . . . . . . . . . . . . . . 4
2.2. RTP Multiplexing . . . . . . . . . . . . . . . . . . . . 6
3. Differentiated Services (Diffserv) . . . . . . . . . . . . . 7
3.1. Diffserv Per-Hop Behaviors (PHBs) . . . . . . . . . . . . 10
3.2. Traffic Classifiers and DSCP Remarking . . . . . . . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Diffserv Interactions . . . . . . . . . . . . . . . . . . . . 13
5.1. Diffserv, Reordering, and Transport Protocols . . . . . . 13
5.2. Diffserv, Reordering, and Real-Time Communication . . . . 15
5.3. Drop Precedence and Transport Protocols . . . . . . . . . 16
5.4. Diffserv and RTCP . . . . . . . . . . . . . . . . . . . . 17
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
This memo describes the interactions between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality [RFC2475] and real-time network communication, including communication based on the Real-time Transport Protocol (RTP) [RFC3550]. Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs) [RFC2474]. In the past, distinct RTP streams have been sent over different transport-level flows, sometimes multiplexed with the RTP Control Protocol (RTCP). WebRTC applications, as well as some conferencing applications, are now using the Session Description Protocol (SDP) [RFC4566] bundle negotiation mechanism [SDP-BUNDLE] to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC traffic [WEBRTC-OVERVIEW].
このメモは、Differentiated Services（Diffserv）ネットワークのサービス品質（QoS）機能[RFC2475]と、リアルタイム転送プロトコル（RTP）[RFC3550]に基づく通信を含むリアルタイムネットワーク通信との間の相互作用について説明します。 Diffservは、IPヘッダーが異なるDiffservコードポイント（DSCP）[RFC2474]でマークされているパケットに異なる転送処理を適用するネットワークノードに基づいています。過去には、個別のRTPストリームがさまざまなトランスポートレベルのフローを介して送信され、RTP制御プロトコル（RTCP）と多重化されることもありました。 WebRTCアプリケーションと一部の会議アプリケーションは、Session Description Protocol（SDP）[RFC4566]バンドルネゴシエーションメカニズム[SDP-BUNDLE]を使用して、同じネットワーク5タプルを使用して、異なるQoS要件を持つ複数のトラフィックストリームを送信します。複数のDSCPを使用して単一のネットワーク5タプル内でさまざまなQoS処理を取得した結果には、特に輻輳制御機能（並べ替えなど）によるトランスポートプロトコルの相互作用があります。さらに、DSCPマーキングは、トラフィックの送信元と宛先の間で変更または削除される場合があります。このメモは、WebRTCトラフィック[WEBRTC-OVERVIEW]を含む、リアルタイムネットワーク通信に対するこれらのDiffservアスペクトの影響をカバーしています。
The memo is organized as follows. Background is provided in Section 2 on real-time communications and Section 3 on Differentiated Services. Section 4 describes some examples of Diffserv usage with real-time communications. Section 5 explains how use of Diffserv features interacts with both transport and real-time communications protocols and Section 6 provides guidance on Diffserv feature usage to control undesired interactions. Security considerations are discussed in Section 7.
メモは以下のように構成されています。背景は、リアルタイム通信のセクション2と差別化サービスのセクション3に記載されています。セクション4では、リアルタイム通信でのDiffservの使用例をいくつか説明します。セクション5は、Diffserv機能の使用がトランスポートプロトコルとリアルタイム通信プロトコルの両方とどのように相互作用するかを説明し、セクション6は、Diffserv機能の使用法に関するガイダンスを提供して、望ましくない相互作用を制御します。セキュリティに関する考慮事項については、セクション7で説明します。
Real-time communications enables communication in real time over an IP network using voice, video, text, content sharing, etc. It is possible to use more than one of these modes concurrently to provide a rich communication experience.
リアルタイム通信により、音声、ビデオ、テキスト、コンテンツ共有などを使用して、IPネットワークを介したリアルタイムの通信が可能になります。これらのモードを複数同時に使用して、豊かな通信体験を提供できます。
A simple example of real-time communications is a voice call placed over the Internet where an audio stream is transmitted in each direction between two users. A more complex example is an immersive videoconferencing system that has multiple video screens, multiple cameras, multiple microphones, and some means of sharing content. For such complex systems, there may be multiple media and non-media streams transmitted via a single IP address and port or via multiple IP addresses and ports.
リアルタイム通信の簡単な例は、インターネット経由で行われる音声通話で、2人のユーザー間で音声ストリームが各方向に送信されます。より複雑な例は、複数のビデオ画面、複数のカメラ、複数のマイク、およびコンテンツを共有するいくつかの手段を備えた没入型ビデオ会議システムです。そのような複雑なシステムの場合、単一のIPアドレスとポートを介して、または複数のIPアドレスとポートを介して送信される複数のメディアストリームと非メディアストリームが存在する可能性があります。
The most common protocol used for real-time media is RTP [RFC3550]. RTP defines a common encapsulation format and handling rules for real-time data transmitted over the Internet. Unfortunately, RTP terminology usage has been inconsistent. For example, RFC 7656 [RFC7656] on RTP terminology observes that:
リアルタイムメディアに使用される最も一般的なプロトコルはRTP [RFC3550]です。 RTPは、インターネット経由で送信されるリアルタイムデータの一般的なカプセル化形式と処理ルールを定義します。残念ながら、RTP用語の使用は一貫していません。たとえば、RTP用語に関するRFC 7656 [RFC7656]は、次のように述べています。
RTP [RFC3550] uses media stream, audio stream, video stream, and a stream of (RTP) packets interchangeably, which are all RTP streams.
RTP [RFC3550]は、メディアストリーム、オーディオストリーム、ビデオストリーム、および（RTP）パケットのストリームを交換可能に使用します。これらはすべてRTPストリームです。
Terminology in this memo is based on that RTP terminology document with the following terms being of particular importance (see that terminology document for full definitions):
このメモの用語は、そのRTP用語ドキュメントに基づいており、次の用語が特に重要です（完全な定義については、その用語ドキュメントを参照してください）。
Source Stream: A reference clock synchronized, time progressing, digital media stream.
ソースストリーム：基準クロックに同期した、時間進行のデジタルメディアストリーム。
RTP Stream: A stream of RTP packets containing media data, which may be source data or redundant data. The RTP stream is identified by an RTP synchronization source (SSRC) belonging to a particular RTP session. An RTP stream may be a secured RTP stream when RTP-based security is used.
RTPストリーム：メディアデータを含むRTPパケットのストリーム。ソースデータまたは冗長データの場合があります。 RTPストリームは、特定のRTPセッションに属するRTP同期ソース（SSRC）によって識別されます。 RTPベースのセキュリティが使用されている場合、RTPストリームは保護されたRTPストリームである可能性があります。
In addition, this memo follows [RFC3550] in using the term "SSRC" to designate both the identifier of an RTP stream and the entity that sends that RTP stream.
さらに、このメモは、[RFC3550]に続き、「SSRC」という用語を使用して、RTPストリームの識別子とそのRTPストリームを送信するエンティティの両方を指定しています。
Media encoding and packetization of a source stream results in a source RTP stream plus zero or more redundancy RTP streams that provide resilience against loss of packets from the source RTP stream [RFC7656]. Redundancy information may also be carried in the same RTP stream as the encoded source stream, e.g., see Section 7.2 of [RFC5109]. With most applications, a single media type (e.g., audio) is transmitted within a single RTP session. However, it is possible to transmit multiple, distinct source streams over the same RTP session as one or more individual RTP streams. This is referred to as RTP multiplexing. In addition, an RTP stream may contain multiple source streams, e.g., components or programs in an MPEG Transport Stream [H.221].
ソースストリームのメディアエンコーディングとパケット化は、ソースRTPストリームに加えて、ソースRTPストリームからのパケットの損失に対する回復力を提供するゼロ以上の冗長RTPストリームをもたらします[RFC7656]。冗長性情報は、エンコードされたソースストリームと同じRTPストリームで搬送される場合もあります。たとえば、[RFC5109]のセクション7.2をご覧ください。ほとんどのアプリケーションでは、単一のメディアタイプ（オーディオなど）が単一のRTPセッション内で送信されます。ただし、1つ以上の個別のRTPストリームとして、同じRTPセッションを介して複数の異なるソースストリームを送信することは可能です。これは、RTP多重化と呼ばれます。さらに、RTPストリームには、MPEGトランスポートストリームのコンポーネントやプログラムなど、複数のソースストリームが含まれる場合があります[H.221]。
The number of source streams and RTP streams in an overall real-time interaction can be surprisingly large. In addition to a voice source stream and a video source stream, there could be separate source streams for each of the cameras or microphones on a videoconferencing system. As noted above, there might also be separate redundancy RTP streams that provide protection to a source RTP stream, using techniques such as forward error correction. Another example is simulcast transmission, where a video source stream can be transmitted as high resolution and low resolution RTP streams at the same time. In this case, a media processing function might choose to send one or both RTP streams onward to a receiver based on bandwidth availability or who the active speaker is in a multipoint conference. Lastly, a transmitter might send the same media content concurrently as two RTP streams using different encodings (e.g., video encoded as VP8 [RFC6386] in parallel with H.264 [H.264]) to allow a media processing function to select a media encoding that best matches the capabilities of the receiver.
全体的なリアルタイムインタラクションにおけるソースストリームとRTPストリームの数は、驚くほど大きくなる可能性があります。音声ソースストリームとビデオソースストリームに加えて、ビデオ会議システムのカメラまたはマイクごとに個別のソースストリームが存在する場合があります。上記のように、フォワードエラー訂正などの手法を使用して、ソースRTPストリームを保護する個別の冗長RTPストリームが存在する場合もあります。別の例はサイマルキャスト送信で、ビデオソースストリームを高解像度と低解像度のRTPストリームとして同時に送信できます。この場合、メディア処理機能は、帯域幅の可用性、またはアクティブな発言者がマルチポイント会議に参加している人に基づいて、1つまたは両方のRTPストリームを受信者に送信することを選択できます。最後に、トランスミッターは同じメディアコンテンツを2つのRTPストリームと同時に送信し、メディア処理機能でメディアを選択できるように、異なるエンコーディング（たとえば、VP8 [RFC6386]とH.264 [H.264]を並行してエンコードしたビデオ）を使用します。受信機の機能に最適なエンコーディング。
For the WebRTC protocol suite [WEBRTC-TRANSPORTS], an individual source stream is a MediaStreamTrack, and a MediaStream contains one or more MediaStreamTracks [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is transmitted as a source RTP stream plus zero or more redundant RTP streams, so a MediaStream that consists of one MediaStreamTrack is transmitted as a single source RTP stream plus zero or more redundant RTP streams. For more information on use of RTP in WebRTC, see [RTP-USAGE].
WebRTCプロトコルスイート[WEBRTC-TRANSPORTS]の場合、個々のソースストリームはMediaStreamTrackであり、MediaStreamには1つ以上のMediaStreamTracks [W3C.WD-mediacapture-streams-20130903]が含まれています。 MediaStreamTrackは、ソースRTPストリームと0個以上の冗長RTPストリームとして送信されるため、1つのMediaStreamTrackで構成されるMediaStreamは、単一のソースRTPストリームと0個以上の冗長RTPストリームとして送信されます。 WebRTCでのRTPの使用の詳細については、[RTP-USAGE]を参照してください。
RTP is usually carried over a datagram protocol, such as UDP [RFC768], UDP-Lite [RFC3828], or the Datagram Congestion Control Protocol (DCCP) [RFC4340]; UDP is most commonly used, but a non-datagram protocol (e.g., TCP [RFC793]) may also be used. Transport protocols other than UDP or UDP-Lite may also be used to transmit real-time data or near-real-time data. For example, the Stream Control Transmission Protocol (SCTP) [RFC4960] can be utilized to carry application-sharing or whiteboarding information as part of an overall interaction that includes real-time media. These additional transport protocols can be multiplexed with an RTP session via UDP encapsulation, thereby using a single pair of UDP ports.
RTPは通常、UDP [RFC768]、UDP-Lite [RFC3828]、Datagram Congestion Control Protocol（DCCP）[RFC4340]などのデータグラムプロトコルで伝送されます。 UDPが最も一般的に使用されますが、非データグラムプロトコル（たとえば、TCP [RFC793]）も使用できます。 UDPまたはUDP-Lite以外のトランスポートプロトコルを使用して、リアルタイムデータまたはほぼリアルタイムのデータを送信することもできます。たとえば、ストリーム制御伝送プロトコル（SCTP）[RFC4960]を利用して、リアルタイムメディアを含む全体的な対話の一部として、アプリケーション共有またはホワイトボード情報を運ぶことができます。これらの追加のトランスポートプロトコルは、UDPカプセル化を介してRTPセッションと多重化できるため、1組のUDPポートを使用できます。
The WebRTC protocol suite encompasses a number of forms of multiplexing:
WebRTCプロトコルスイートには、多数の形式の多重化が含まれます。
1. Individual source streams are carried in one or more individual RTP streams. These RTP streams can be multiplexed onto a single transport-layer flow or sent as separate transport-layer flows. This memo only considers the case where the RTP streams are to be multiplexed onto a single transport-layer flow, forming a single RTP session as described in [RFC3550];
1. 個別のソースストリームは、1つ以上の個別のRTPストリームで伝送されます。これらのRTPストリームは、単一のトランスポート層フローに多重化するか、個別のトランスポート層フローとして送信できます。このメモは、RTPストリームが単一のトランスポート層フローに多重化され、[RFC3550]で説明されているように単一のRTPセッションを形成する場合のみを考慮します。
2. RTCP (see [RFC3550]) may be multiplexed onto the same transport-layer flow as the RTP streams with which it is associated, as described in [RFC5761], or it may be sent on a separate transport-layer flow;
2. RTCP（[RFC3550]を参照）は、[RFC5761]で説明されているように、関連付けられているRTPストリームと同じトランスポート層フローに多重化するか、または別のトランスポート層フローで送信できます。
3. An RTP session could be multiplexed with a single SCTP association over Datagram Transport Layer Security (DTLS) and with both Session Traversal Utilities for NAT (STUN) [RFC5389] and TURN [RFC5766] traffic into a single transport-layer flow as described in [RFC5764] with the updates in [SRTP-DTLS]. The STUN [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] protocols provide NAT/FW (Network Address Translator / Firewall) traversal and port mapping.
3. RTPセッションは、[ RFC5764] [SRTP-DTLS]の更新STUN [RFC5389]とNAT周囲のリレーを使用したトラバーサル（TURN）[RFC5766]プロトコルは、NAT / FW（Network Address Translator / Firewall）トラバーサルとポートマッピングを提供します。
The resulting transport-layer flow is identified by a network 5-tuple, i.e., a combination of two IP addresses (source and destination), two ports (source and destination), and the transport protocol used (e.g., UDP). SDP bundle negotiation restrictions [SDP-BUNDLE] limit WebRTC to using at most a single DTLS session per network 5-tuple. In contrast to WebRTC use of a single SCTP association with DTLS, multiple SCTP associations can be directly multiplexed over a single UDP 5-tuple as specified in [RFC6951].
結果のトランスポート層フローは、ネットワーク5タプル、つまり2つのIPアドレス（送信元と宛先）、2つのポート（送信元と宛先）、および使用されるトランスポートプロトコル（UDPなど）の組み合わせによって識別されます。 SDPバンドルネゴシエーション制限[SDP-BUNDLE]は、WebRTCがネットワーク5タプルあたり最大1つのDTLSセッションを使用するように制限します。 WebRTCがDTLSと単一のSCTPアソシエーションを使用するのとは対照的に、[RFC6951]で指定されているように、複数のSCTPアソシエーションを単一のUDP 5タプルで直接多重化できます。
The STUN and TURN protocols were originally designed to use UDP as a transport; however, TURN has been extended to use TCP as a transport for situations in which UDP does not work [RFC6062]. When TURN selects use of TCP, the entire real-time communications session is carried over a single TCP connection (i.e., 5-tuple).
STUNおよびTURNプロトコルは、もともとUDPをトランスポートとして使用するように設計されていました。ただし、TURNは、UDPが機能しない状況のトランスポートとしてTCPを使用するように拡張されています[RFC6062]。 TURNがTCPの使用を選択すると、リアルタイム通信セッション全体が単一のTCP接続（つまり、5タプル）を介して実行されます。
For IPv6, addition of the flow label [RFC6437] to network 5-tuples results in network 6-tuples (or 7-tuples for bidirectional flows), but in practice, use of a flow label is unlikely to result in a finer-grain traffic subset than the corresponding network 5-tuple (e.g., the flow label is likely to represent the combination of two ports with use of the UDP protocol). For that reason, discussion in this document focuses on UDP 5-tuples.
IPv6の場合、フローラベル[RFC6437]をネットワーク5タプルに追加すると、ネットワーク6タプル（または双方向フローの場合は7タプル）が作成されますが、実際には、フローラベルを使用しても細かい粒度になることはほとんどありません。対応するネットワーク5タプルよりもトラフィックのサブセット（たとえば、フローラベルは、UDPプロトコルを使用した2つのポートの組み合わせを表す可能性があります）。そのため、このドキュメントでは、UDP 5タプルに焦点を当てています。
Section 2.1 explains how source streams can be multiplexed in a single RTP session, which can in turn be multiplexed over UDP with packets generated by other transport protocols. This section provides background on why this level of multiplexing is desirable. The rationale in this section applies both to multiplexing of source streams in a single RTP session and multiplexing of an RTP session with traffic from other transport protocols via UDP encapsulation.
セクション2.1では、単一のRTPセッションでソースストリームを多重化する方法について説明します。このRTPセッションは、他のトランスポートプロトコルによって生成されたパケットとUDPを介して多重化できます。このセクションでは、このレベルの多重化が望ましい理由について説明します。このセクションの根拠は、単一のRTPセッションでのソースストリームの多重化と、UDPカプセル化を介した他のトランスポートプロトコルからのトラフィックによるRTPセッションの多重化の両方に適用されます。
Multiplexing reduces the number of ports utilized for real-time and related communication in an overall interaction. While a single endpoint might have plenty of ports available for communication, this traffic often traverses points in the network that are constrained on the number of available ports or whose performance degrades as the number of ports in use increases. A good example is a NAT/FW device sitting at the network edge. As the number of simultaneous protocol sessions increases, so does the burden placed on these devices to provide port mapping.
多重化により、全体的な相互作用でリアルタイムおよび関連する通信に使用されるポートの数が減少します。単一のエンドポイントには通信に使用できるポートがたくさんある場合がありますが、このトラフィックは、使用可能なポートの数に制限されている、または使用中のポートの数が増えるとパフォーマンスが低下するネットワーク内のポイントを通過することがよくあります。良い例は、ネットワークエッジにあるNAT / FWデバイスです。同時プロトコルセッションの数が増えると、ポートマッピングを提供するためにこれらのデバイスにかかる負担も増えます。
Another reason for multiplexing is to help reduce the time required to establish bidirectional communication. Since any two communicating users might be situated behind different NAT/FW devices, it is necessary to employ techniques like STUN and TURN along with Interactive Connectivity Establishment (ICE) [RFC5245] to get traffic to flow between the two devices [WEBRTC-TRANSPORTS]. Performing the tasks required by these protocols takes time, especially when multiple protocol sessions are involved. While tasks for different sessions can be performed in parallel, it is nonetheless necessary for applications to wait for all sessions to be opened before communication between two users can begin. Reducing the number of STUN/ICE/TURN steps reduces the likelihood of loss of a packet for one of these protocols; any such loss adds delay to setting up a communication session. Further, reducing the number of STUN/ICE/TURN tasks places a lower burden on the STUN and TURN servers.
多重化するもう1つの理由は、双方向通信の確立に必要な時間を短縮するためです。通信している2人のユーザーが異なるNAT / FWデバイスの背後にいる可能性があるため、2つのデバイス間でトラフィックが流れるようにするには、STUNやTURNなどの技術とInteractive Connectivity Establishment（ICE）[RFC5245]を併用する必要があります[WEBRTC-TRANSPORTS] 。特に複数のプロトコルセッションが関係している場合、これらのプロトコルで必要なタスクの実行には時間がかかります。異なるセッションのタスクを並行して実行できますが、それでもなお、2人のユーザー間の通信を開始する前に、アプリケーションがすべてのセッションが開かれるのを待つ必要があります。 STUN / ICE / TURNステップの数を減らすと、これらのプロトコルの1つでパケットが失われる可能性が低くなります。そのような損失は、通信セッションのセットアップに遅延を追加します。さらに、STUN / ICE / TURNタスクの数を減らすと、STUNサーバーとTURNサーバーへの負荷が軽減されます。
Multiplexing may reduce the complexity and resulting load on an endpoint. A single instance of STUN/ICE/TURN is simpler to execute and manage than multiple instances STUN/ICE/TURN operations happening in parallel, as the latter require synchronization and create more complex failure situations that have to be cleaned up by additional code.
多重化により、複雑さが軽減され、エンドポイントの負荷が軽減される場合があります。 STUN / ICE / TURNの単一のインスタンスは、並行して発生する複数のインスタンスのSTUN / ICE / TURN操作よりも実行と管理が簡単です。後者は同期を必要とし、追加のコードでクリーンアップする必要があるより複雑な障害状況を作成するためです。
The Diffserv architecture [RFC2475][RFC4594] is intended to enable scalable service discrimination in the Internet without requiring each node in the network to store per-flow state and participate in per-flow signaling. The services may be end to end or within a network; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of well-defined building blocks deployed in network nodes that:
Diffservアーキテクチャ[RFC2475] [RFC4594]は、ネットワーク内の各ノードがフローごとの状態を保存し、フローごとのシグナリングに参加する必要なく、インターネットでスケーラブルなサービスの識別を可能にすることを目的としています。サービスは、エンドツーエンドまたはネットワーク内にあります。これらには、定量的なパフォーマンス要件を満たすことができるもの（たとえば、ピーク帯域幅）と、相対的なパフォーマンスに基づくもの（たとえば、「クラス」の区別）の両方が含まれます。サービスは、ネットワークノードに展開された明確に定義されたビルディングブロックの組み合わせによって構築できます。
o classify traffic and set bits in an IP header field at network boundaries or hosts,
o トラフィックを分類し、ネットワーク境界またはホストのIPヘッダーフィールドにビットを設定します。
o use those bits to determine how packets are forwarded by the nodes inside the network, and
o これらのビットを使用して、ネットワーク内のノードがパケットを転送する方法を決定します。
o condition the marked packets at network boundaries in accordance with the requirements or rules of each service.
o 各サービスの要件またはルールに従って、マークされたパケットをネットワーク境界で調整します。
Traffic conditioning may include changing the DSCP in a packet (remarking it), delaying the packet (as a consequence of traffic shaping), or dropping the packet (as a consequence of traffic policing).
トラフィックの調整には、パケット内のDSCPの変更（再マーキング）、パケットの遅延（トラフィックシェーピングの結果）、またはパケットのドロップ（トラフィックポリシングの結果）が含まれます。
A network node that supports Diffserv includes a classifier that selects packets based on the value of the DS field in IP headers (the Diffserv codepoint or DSCP), along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and fine-grain conditioning of marked packets need only be performed at network boundaries; internal network nodes operate on traffic aggregates that share a DS field value, or in some cases, a small set of related values.
Diffservをサポートするネットワークノードには、IPヘッダー（DiffservコードポイントまたはDSCP）のDSフィールドの値に基づいてパケットを選択する分類子と、によって示される特定のパケット転送処理を配信できるバッファー管理およびパケットスケジューリングメカニズムが含まれますDSフィールド値。 DSフィールドの設定とマークされたパケットのきめ細かい調整は、ネットワーク境界でのみ実行する必要があります。内部ネットワークノードは、DSフィールド値、または場合によっては、関連する値の小さなセットを共有するトラフィック集合体で動作します。
The Diffserv architecture [RFC2475] maintains distinctions among:
Diffservアーキテクチャ[RFC2475]は、以下の違いを維持しています。
o the QoS service provided to a traffic aggregate,
o トラフィック集合体に提供されるQoSサービス
o the conditioning functions and per-hop behaviors (PHBs) used to realize services,
o サービスを実現するために使用されるコンディショニング機能とホップごとの動作（PHB）、
o the DSCP in the IP header used to mark packets to select a per-hop behavior, and
o ホップごとの動作を選択するためにパケットをマークするために使用されるIPヘッダーのDSCP、および
o the particular implementation mechanisms that realize a per-hop behavior.
o ホップごとの動作を実現する特定の実装メカニズム。
This memo focuses on PHBs and the usage of DSCPs to obtain those behaviors. In a network node's forwarding path, the DSCP is used to map a packet to a particular forwarding treatment, or to a per-hop behavior (PHB) that specifies the forwarding treatment.
このメモは、PHBおよびそれらの動作を取得するためのDSCPの使用に焦点を当てています。ネットワークノードの転送パスでは、DSCPを使用して、パケットを特定の転送処理、または転送処理を指定するホップ単位の動作（PHB）にマップします。
The specification of a PHB describes the externally observable forwarding behavior of a network node for network traffic marked with a DSCP that selects that PHB. In this context, "forwarding behavior" is a general concept - for example, if only one DSCP is used for all traffic on a link, the observable forwarding behavior (e.g., loss, delay, jitter) will often depend only on the loading of the link. To obtain useful behavioral differentiation, multiple traffic subsets are marked with different DSCPs for different PHBs for which node resources such as buffer space and bandwidth are allocated. PHBs provide the framework for a Diffserv network node to allocate resources to traffic subsets, with network-scope Differentiated Services constructed on top of this basic hop-by-hop resource allocation mechanism.
PHBの仕様は、そのPHBを選択するDSCPでマークされたネットワークトラフィックに対するネットワークノードの外部から観察可能な転送動作を記述します。このコンテキストでは、「転送動作」は一般的な概念です。たとえば、リンク上のすべてのトラフィックに1つのDSCPのみが使用されている場合、観察可能な転送動作（損失、遅延、ジッターなど）は多くの場合、リンク。有用な動作の差別化を実現するために、複数のトラフィックサブセットは、バッファスペースや帯域幅などのノードリソースが割り当てられているさまざまなPHBのさまざまなDSCPでマークされています。 PHBは、Diffservネットワークノードがトラフィックサブセットにリソースを割り当てるためのフレームワークを提供します。ネットワークスコープの差別化サービスは、この基本的なホップバイホップのリソース割り当てメカニズムの上に構築されます。
The codepoints (DSCPs) may be chosen from a small set of fixed values (the class selector codepoints), from a set of recommended values defined in PHB specifications, or from values that have purely local meanings to a specific network that supports Diffserv; in general, packets may be forwarded across multiple such networks between source and destination.
コードポイント（DSCP）は、固定値の小さなセット（クラスセレクターコードポイント）、PHB仕様で定義された推奨値のセット、またはDiffservをサポートする特定のネットワークに対して純粋にローカルな意味を持つ値から選択できます。一般に、パケットは、送信元と宛先の間の複数のそのようなネットワークを介して転送されます。
The mandatory DSCPs are the class selector codepoints as specified in [RFC2474]. The class selector codepoints (CS0-CS7) extend the deprecated concept of IP Precedence in the IPv4 header; three bits are added, so that the class selector DSCPs are of the form 'xxx000'. The all-zero DSCP ('000000' or CS0) is always assigned to a Default PHB that provides best-effort forwarding behavior, and the remaining class selector codepoints are intended to provide relatively better per-hop-forwarding behavior in increasing numerical order, but:
必須のDSCPは、[RFC2474]で指定されているクラスセレクタコードポイントです。クラスセレクターコードポイント（CS0〜CS7）は、IPv4ヘッダーの非推奨のIP Precedenceの概念を拡張します。 3ビットが追加されるため、クラスセレクタDSCPは「xxx000」の形式になります。すべてゼロのDSCP（ '000000'またはCS0）は、常にデフォルトのPHBに割り当てられ、ベストエフォート型の転送動作を提供します。残りのクラスセレクターコードポイントは、番号順で比較的良好なホップごとの転送動作を提供することを目的としています。だが：
o A network endpoint cannot rely upon different class selector codepoints providing Differentiated Services via assignment to different PHBs, as adjacent class selector codepoints may use the same pool of resources on each network node in some networks. This generalizes to ranges of class selector codepoints, but with limits -- for example, CS6 and CS7 are often used for network control (e.g., routing) traffic [RFC4594] and hence are likely to provide better forwarding behavior under network load to prioritize network recovery from disruptions. There is no effective way for a network endpoint to determine which PHBs are selected by the class selector codepoints on a specific network, let alone end to end.
o 一部のネットワークでは、隣接するクラスセレクターコードポイントが各ネットワークノード上の同じリソースプールを使用する場合があるため、ネットワークエンドポイントは、異なるPHBへの割り当てを介して差別化サービスを提供する異なるクラスセレクターコードポイントに依存できません。これは、クラスセレクターコードポイントの範囲に一般化されますが、制限があります。たとえば、CS6とCS7は、ネットワーク制御（ルーティングなど）トラフィックによく使用されます[RFC4594]。したがって、ネットワークを優先してネットワーク負荷の下でより良い転送動作を提供する可能性があります。混乱からの回復。ネットワークエンドポイントが特定のネットワークのクラスセレクターコードポイントによって選択されるPHBを決定する効果的な方法はありません。
o CS1 ('001000') was subsequently designated as the recommended codepoint for the Lower Effort (LE) PHB [RFC3662]. An LE service forwards traffic with "lower" priority than best effort and can be "starved" by best-effort and other "higher" priority traffic. Not all networks offer an LE service, hence traffic marked with the CS1 DSCP may not receive lower effort forwarding; such traffic may be forwarded with a different PHB (e.g., the Default PHB), remarked to another DSCP (e.g., CS0) and forwarded accordingly, or dropped. A network endpoint cannot rely upon the presence of an LE service that is selected by the CS1 DSCP on a specific network, let alone end to end. Packets marked with the CS1 DSCP may be forwarded with best-effort service or another "higher" priority service; see [RFC2474]. See [RFC3662] for further discussion of the LE PHB and service.
o CS1（ '001000'）はその後、Lower Effort（LE）PHB [RFC3662]の推奨コードポイントとして指定されました。 LEサービスは、ベストエフォートよりも「優先度が低い」トラフィックを転送し、ベストエフォートおよびその他の「優先度が高い」トラフィックによって「枯渇」する可能性があります。すべてのネットワークがLEサービスを提供するわけではないため、CS1 DSCPでマークされたトラフィックは、より少ないエフォートの転送を受信しない場合があります。このようなトラフィックは、別のPHB（デフォルトのPHBなど）で転送されたり、別のDSCP（CS0など）に再マーキングされたり、それに応じて転送されたり、ドロップされたりすることがあります。ネットワークエンドポイントは、特定のネットワーク上のCS1 DSCPによって選択されたLEサービスの存在に依存することはできません。 CS1 DSCPでマークされたパケットは、ベストエフォートサービスまたは別の「より高い」優先度サービスで転送できます。 [RFC2474]を参照してください。 LE PHBとサービスの詳細については、[RFC3662]を参照してください。
Although Differentiated Services is a general architecture that may be used to implement a variety of services, three fundamental forwarding behaviors (PHBs) have been defined and characterized for general use. These are:
Differentiated Servicesはさまざまなサービスの実装に使用できる一般的なアーキテクチャですが、3つの基本的な転送動作（PHB）が定義され、一般的な使用のために特徴付けられています。これらは：
1. Default Forwarding (DF) for elastic traffic [RFC2474]. The Default PHB is always selected by the all-zero DSCP and provides best-effort forwarding.
1. エラスティックトラフィックのデフォルト転送（DF）[RFC2474]。デフォルトのPHBは常にすべてゼロのDSCPによって選択され、ベストエフォート型の転送を提供します。
2. Assured Forwarding (AF) [RFC2597] to provide Differentiated Service to elastic traffic. Each instance of the AF behavior consists of three PHBs that differ only in drop precedence, e.g., AF11, AF12, and AF13; such a set of three AF PHBs is referred to as an AF class, e.g., AF1x. There are four defined AF classes, AF1x through AF4x, with higher numbered classes intended to receive better forwarding treatment than lower numbered classes. Use of multiple PHBs from a single AF class (e.g., AF1x) does not enable network traffic reordering within a single network 5-tuple, although such reordering may occur for other transient reasons (e.g., routing changes or ECMP rebalancing).
2. 弾性転送に差別化サービスを提供するための保証転送（AF）[RFC2597]。 AF動作の各インスタンスは、ドロップの優先順位のみが異なる3つのPHBで構成されています（例：AF11、AF12、AF13）。そのような３つのＡＦ ＰＨＢのセットは、ＡＦクラス、例えば、ＡＦ１ｘと呼ばれる。 AF1xからAF4xの4つの定義済みAFクラスがあり、番号が大きいクラスは、番号が小さいクラスよりも優れた転送処理を受けることを目的としています。単一のAFクラス（AF1xなど）から複数のPHBを使用しても、単一のネットワーク5タプル内でのネットワークトラフィックの並べ替えは有効になりませんが、そのような並べ替えは他の一時的な理由（ルーティングの変更やECMP再調整など）で発生する可能性があります。
3. Expedited Forwarding (EF) [RFC3246] intended for inelastic traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] is an admission-controlled variant of the EF PHB. Both of these PHBs are based on preconfigured limited forwarding capacity; traffic in excess of that capacity is expected to be dropped.
3. 非弾性トラフィック向けのExpedited Forwarding（EF）[RFC3246]。基本的なEF PHBを超えて、VOICE-ADMIT PHB [RFC5865]は、EF PHBのアドミッション制御バリアントです。これらのPHBは両方とも、事前構成された限られた転送容量に基づいています。その容量を超えるトラフィックはドロップされることが予想されます。
DSCP markings are not end to end in general. Each network can make its own decisions about what PHBs to use and which DSCP maps to each PHB. While every PHB specification includes a recommended DSCP, and RFC 4594 [RFC4594] recommends their end-to-end usage, there is no requirement that every network support any PHBs (aside from the Default PHB for best-effort forwarding) or use any specific DSCPs, with the exception of the support requirements for the class selector codepoints (see RFC 2474 [RFC2474]). When Diffserv is used, the edge or boundary nodes of a network are responsible for ensuring that all traffic entering that network conforms to that network's policies for DSCP and PHB usage, and such nodes may change DSCP markings on traffic to achieve that result. As a result, DSCP remarking is possible at any network boundary, including the first network node that traffic sent by a host encounters. Remarking is also possible within a network, e.g., for traffic shaping.
DSCPマーキングは一般的にエンドツーエンドではありません。各ネットワークは、使用するPHBと、各PHBにマップするDSCPについて独自の決定を行うことができます。すべてのPHB仕様には推奨DSCPが含まれており、RFC 4594 [RFC4594]はエンドツーエンドの使用を推奨していますが、すべてのネットワークがPHBをサポートする（ベストエフォート転送のデフォルトPHBを除く）か、特定のクラスセレクターコードポイントのサポート要件を除いて、DSCP（RFC 2474 [RFC2474]を参照）。 Diffservを使用する場合、ネットワークのエッジノードまたは境界ノードは、そのネットワークに入るすべてのトラフィックがDSCPおよびPHBの使用に関するそのネットワークのポリシーに準拠していることを確認する責任があります。そのようなノードは、トラフィックのDSCPマーキングを変更して、その結果を達成できます。その結果、DSCP再マーキングは、ホストから送信されたトラフィックが遭遇する最初のネットワークノードを含め、どのネットワーク境界でも可能です。トラフィックシェーピングなど、ネットワーク内でもリマーキングが可能です。
DSCP remarking is part of traffic conditioning; the traffic conditioning functionality applied to packets at a network node is determined by a traffic classifier [RFC2475]. Edge nodes of a Diffserv network classify traffic based on selected packet header fields; typical implementations do not look beyond the traffic's network 5-tuple in the IP and transport protocol headers (e.g., for SCTP or RTP encapsulated in UDP, header-based classification is unlikely to look beyond the outer UDP header). As a result, when multiple DSCPs are used for traffic that shares a network 5-tuple, remarking at a network boundary may result in all of the traffic being forwarded with a single DSCP, thereby removing any differentiation within the network 5-tuple downstream of the remarking location. Network nodes within a Diffserv network generally classify traffic based solely on DSCPs, but may perform finer-grain traffic conditioning similar to that performed by edge nodes.
DSCPリマーキングはトラフィック調整の一部です。ネットワークノードでパケットに適用されるトラフィック調整機能は、トラフィック分類子[RFC2475]によって決定されます。 Diffservネットワークのエッジノードは、選択されたパケットヘッダーフィールドに基づいてトラフィックを分類します。典型的な実装は、IPおよびトランスポートプロトコルヘッダーでトラフィックのネットワーク5タプルを超えないようにします（たとえば、UDPにカプセル化されたSCTPまたはRTPの場合、ヘッダーベースの分類は、外部UDPヘッダーを超えて見える可能性はほとんどありません）。その結果、ネットワーク5タプルを共有するトラフィックに複数のDSCPが使用されている場合、ネットワーク境界で再マーキングすると、すべてのトラフィックが単一のDSCPで転送され、それにより、ネットワーク5タプルのダウンストリームの差異が取り除かれます。発言場所。 Diffservネットワーク内のネットワークノードは通常、DSCPのみに基づいてトラフィックを分類しますが、エッジノードによって実行されるものと同様のよりきめ細かいトラフィック調整を実行する場合があります。
So, for two arbitrary network endpoints, there can be no assurance that the DSCP set at the source endpoint will be preserved and presented at the destination endpoint. Rather, it is quite likely that the DSCP will be set to zero (e.g., at the boundary of a network operator that distrusts or does not use the DSCP field) or to a value deemed suitable by an ingress classifier for whatever network 5-tuple it carries.
したがって、2つの任意のネットワークエンドポイントの場合、ソースエンドポイントで設定されたDSCPが保存され、宛先エンドポイントで提示されるという保証はありません。むしろ、DSCPがゼロに設定される（たとえば、DSCPフィールドを信頼しないか、または使用しないネットワークオペレーターの境界で）、またはネットワーク5タプルの入力分類子によって適切と見なされる値に設定される可能性が非常に高い運ぶ。
In addition, remarking may remove application-level distinctions in forwarding behavior - e.g., if multiple PHBs within an AF class are used to distinguish different types of frames within a video RTP stream, token-bucket-based remarkers operating in color-blind mode (see [RFC2697] and [RFC2698] for examples) may remark solely based on flow rate and burst behavior, removing the drop precedence distinctions specified by the source.
さらに、リマーキングにより、転送動作のアプリケーションレベルの違いが取り除かれる可能性があります。たとえば、AFクラス内の複数のPHBがビデオRTPストリーム内の異なるタイプのフレームを区別するために使用される場合、トークンバケットベースのリマーカーはカラーブラインドモードで動作します（ [RFC2697]と[RFC2698]の例を参照してください）は、流量とバーストの動作のみに基づいてコメントし、ソースによって指定されたドロップ優先順位の違いを取り除くことができます。
Backbone and other carrier networks may employ a small number of DSCPs (e.g., less than half a dozen) to manage a small number of traffic aggregates; hosts that use a larger number of DSCPs can expect to find that much of their intended differentiation is removed by such networks. Better results may be achieved when DSCPs are used to spread traffic among a smaller number of Diffserv-based traffic subsets or aggregates; see [DIFFSERV-INTERCON] for one proposal. This is of particular importance for MPLS-based networks due to the limited size of the Traffic Class (TC) field in an MPLS label [RFC5462] that is used to carry Diffserv information and the use of that TC field for other purposes, e.g., Explicit Congestion Notification (ECN) [RFC5129]. For further discussion on use of Diffserv with MPLS, see [RFC3270] and [RFC5127].
バックボーンおよびその他のキャリアネットワークは、少数のDSCP（たとえば、6ダース未満）を使用して、少数のトラフィック集約を管理する場合があります。多数のDSCPを使用するホストは、意図した差異の多くがそのようなネットワークによって削除されることを期待できます。 DSCPを使用してトラフィックを少数のDiffservベースのトラフィックサブセットまたは集約に分散すると、より良い結果が得られる場合があります。 1つの提案については、[DIFFSERV-INTERCON]を参照してください。これは、Diffserv情報を運ぶために使用されるMPLSラベル[RFC5462]のトラフィッククラス（TC）フィールドのサイズに制限があるため、MPLSベースのネットワークにとって特に重要であり、そのTCフィールドは他の目的で使用されます。明示的な輻輳通知（ECN）[RFC5129]。 MPLSでのDiffservの使用に関する詳細については、[RFC3270]および[RFC5127]を参照してください。
For real-time communications, one might want to mark the audio packets using EF and the video packets as AF41. However, a video conference receiving the audio packets significantly ahead of the video is not useful because lip sync is necessary between audio and video. It may still be desirable to send audio with a PHB that provides better service, because more reliable arrival of audio helps assure smooth audio rendering, which is often more important than fully faithful video rendering. There are also limits, as some devices have difficulties in synchronizing voice and video when packets that need to be rendered together arrive at significantly different times. It makes more sense to use different PHBs when the audio and video source streams do not share a strict timing relationship. For example, video content may be shared within a video conference via playback, perhaps of an unedited video clip that is intended to become part of a television advertisement. Such content sharing video does not need precise synchronization with video conference audio, and could use a different PHB, as content sharing video is more tolerant to jitter, loss, and delay.
リアルタイム通信の場合、EFを使用してオーディオパケットとAF41としてビデオパケットをマークすることができます。ただし、オーディオパケットとビデオのかなり先にオーディオパケットを受信するビデオ会議は、オーディオとビデオの間でリップシンクが必要になるため、役に立ちません。より信頼性の高いオーディオの到着はスムーズなオーディオレンダリングの保証に役立つため、PHBでオーディオを送信してより良いサービスを提供することが望ましい場合があります。これは、完全に忠実なビデオレンダリングよりも重要です。一部のデバイスでは、一緒にレンダリングする必要のあるパケットが大幅に異なる時間に到着すると、音声とビデオの同期が困難になるため、制限もあります。オーディオとビデオのソースストリームが厳密なタイミング関係を共有していない場合は、異なるPHBを使用する方が理にかなっています。例えば、ビデオコンテンツは、おそらくテレビ広告の一部になることを目的とする未編集のビデオクリップの再生を介して、ビデオ会議内で共有することができる。このようなコンテンツ共有ビデオは、ビデオ会議の音声と正確に同期する必要はなく、コンテンツ共有ビデオの方がジッタ、損失、および遅延に耐性があるため、別のPHBを使用できます。
Within a layered video RTP stream, ordering of frame communication is preferred, but importance of frame types varies, making use of PHBs with different drop precedences appropriate. For example, I-frames that contain an entire image are usually more important than P-frames that contain only changes from the previous image because loss of a P-frame (or part thereof) can be recovered (at the latest) via the next I-frame, whereas loss of an I-frame (or part thereof) may cause rendering problems for all of the P-frames that depend on the missing I-frame. For this reason, it is appropriate to mark I-frame packets with a PHB that has lower drop precedence than the PHB used for P-frames, as long as the PHBs preserve ordering among frames (e.g., are in a single AF class) - AF41 for I-frames and AF43 for P-frames is one possibility. Additional spatial and temporal layers beyond the base video layer could also be marked with higher drop precedence than the base video layer, as their loss reduces video quality, but does not disrupt video rendering.
階層化されたビデオRTPストリーム内では、フレーム通信の順序が優先されますが、フレームタイプの重要性はさまざまであり、ドロップ優先度の異なるPHBを適切に利用します。たとえば、画像全体を含むIフレームは通常、前の画像からの変更のみを含むPフレームよりも重要です。これは、Pフレーム（またはその一部）の損失を（遅くとも）次の方法で回復できるためです。一方、Iフレーム（またはその一部）が失われると、失われたIフレームに依存するすべてのPフレームでレンダリングの問題が発生する可能性があります。このため、PHBがフレーム間の順序を維持している（たとえば、単一のAFクラスにある）限り、Pフレームに使用されるPHBよりもドロップ優先度の低いPHBでIフレームパケットをマークすることが適切です。 IフレームにはAF41、PフレームにはAF43が1つの可能性です。ベースビデオレイヤーを超えた追加の空間レイヤーと時間レイヤーも、それらが失われるとビデオ品質が低下しますが、ビデオレンダリングが中断されないため、ベースビデオレイヤーよりも高いドロップ優先度でマークできます。
Additional RTP streams in a real-time communication interaction could be marked with CS0 and carried as best-effort traffic. One example is real-time text transmitted as specified in RFC 4103 [RFC4103]. Best-effort forwarding suffices because such real-time text has loose timing requirements; RFC 4103 recommends sending text in chunks every 300 ms. Such text is technically real-time, but does not need a PHB promising better service than best effort, in contrast to audio or video.
リアルタイム通信インタラクションの追加のRTPストリームは、CS0でマークされ、ベストエフォートトラフィックとして伝送されます。 1つの例は、RFC 4103 [RFC4103]で指定されているように送信されるリアルタイムテキストです。このようなリアルタイムテキストには緩やかなタイミング要件があるため、ベストエフォート型の転送で十分です。 RFC 4103では、300ミリ秒ごとにテキストをチャンクで送信することを推奨しています。このようなテキストは技術的にはリアルタイムですが、音声やビデオとは異なり、ベストエフォートよりも優れたサービスを約束するPHBを必要としません。
A WebRTC application may use one or more RTP streams, as discussed above. In addition, it may use an SCTP-based data channel [DATA-CHAN] whose QoS treatment depends on the nature of the application. For example, best-effort treatment of data channels is likely to suffice for messaging, shared white board, and guided browsing applications, whereas latency-sensitive games might desire better QoS for their data channels.
上で説明したように、WebRTCアプリケーションは1つ以上のRTPストリームを使用できます。さらに、QoS処理がアプリケーションの性質に依存するSCTPベースのデータチャネル[DATA-CHAN]を使用する場合があります。たとえば、データチャネルのベストエフォート型の処理は、メッセージング、共有ホワイトボード、およびガイド付きブラウジングアプリケーションには十分である可能性があります。
Transport protocols provide data communication behaviors beyond those possible at the IP layer. An important example is that TCP [RFC793] provides reliable in-order delivery of data with congestion control. SCTP [RFC4960] provides additional properties such as preservation of message boundaries, and the ability to avoid head-of-line blocking that may occur with TCP.
トランスポートプロトコルは、IP層で可能なものを超えるデータ通信動作を提供します。重要な例は、TCP [RFC793]が輻輳制御を備えたデータの信頼できる順序どおりの配信を提供することです。 SCTP [RFC4960]は、メッセージ境界の保持や、TCPで発生する可能性がある行頭ブロッキングを回避する機能などの追加のプロパティを提供します。
In contrast, UDP [RFC768] is a basic unreliable datagram protocol that provides port-based multiplexing and demultiplexing on top of IP. Two other unreliable datagram protocols are UDP-Lite [RFC3828], a variant of UDP that may deliver partially corrupt payloads when errors occur, and DCCP [RFC4340], which provides a range of congestion control modes for its unreliable datagram service.
対照的に、UDP [RFC768]は、IP上でポートベースの多重化と逆多重化を提供する、基本的な信頼性の低いデータグラムプロトコルです。他の2つの信頼性の低いデータグラムプロトコルは、UDPのバリアントであるUDP-Lite [RFC3828]です。これは、エラーが発生したときに部分的に破損したペイロードを配信する可能性があります。DCCP[RFC4340]は、信頼性の低いデータグラムサービスにさまざまな輻輳制御モードを提供します。
Transport protocols that provide reliable delivery (e.g., TCP, SCTP) are sensitive to network reordering of traffic. When a protocol that provides reliable delivery receives a packet other than the next expected packet, the protocol usually assumes that the expected packet has been lost and updates the peer, which often causes a retransmission. In addition, congestion control functionality in transport protocols (including DCCP) usually infers congestion when packets are lost. This creates additional sensitivity to significant network packet reordering, as such reordering may be (mis)interpreted as loss of the out-of-order packets, causing a congestion control response.
信頼性の高い配信を提供するトランスポートプロトコル（TCP、SCTPなど）は、ネットワークのトラフィックの並べ替えの影響を受けます。信頼性の高い配信を提供するプロトコルが次の予期されるパケット以外のパケットを受信すると、プロトコルは通常、予期されるパケットが失われたと想定し、ピアを更新するため、再送信が発生することがよくあります。さらに、トランスポートプロトコル（DCCPを含む）の輻輳制御機能は、通常、パケットが失われたときに輻輳を推測します。これは、重要なネットワークパケットの並べ替えに対する追加の感度を作成します。そのような並べ替えは、順不同のパケットの損失として（誤って）解釈され、輻輳制御応答を引き起こします。
This sensitivity to reordering remains even when ECN [RFC3168] is in use, as ECN receivers are required to treat missing packets as potential indications of congestion, because:
ECN [RFC3168]を使用している場合でも、この順序変更に対する感度は変わりません。ECN受信者は、失われたパケットを輻輳の潜在的な兆候として扱う必要があるためです。
o Severe congestion may cause ECN-capable network nodes to drop packets, and
o 深刻な輻輳により、ECN対応ネットワークノードがパケットをドロップする可能性があります。
o ECN traffic may be forwarded by network nodes that do not support ECN and hence drop packets to indicate congestion.
o ECNトラフィックは、ECNをサポートしていないネットワークノードによって転送される可能性があるため、パケットをドロップして輻輳を示します。
Congestion control is an important aspect of the Internet architecture; see [RFC2914] for further discussion.
輻輳制御は、インターネットアーキテクチャの重要な側面です。詳細については、[RFC2914]を参照してください。
In general, marking packets with different DSCPs results in different PHBs being applied at nodes in the network, making reordering very likely due to use of different pools of forwarding resources for each PHB. This should not be done within a single network 5-tuple for current transport protocols, with the important exceptions of UDP and UDP-Lite.
一般に、異なるDSCPでパケットをマーキングすると、ネットワーク内のノードで異なるPHBが適用され、PHBごとに転送リソースの異なるプールを使用するため、並べ替えが発生する可能性が高くなります。これは、UDPとUDP-Liteの重要な例外を除いて、現在のトランスポートプロトコルの単一ネットワーク5タプル内では実行しないでください。
When PHBs that enable reordering are mixed within a single network 5-tuple, the effect is to mix QoS-based traffic classes within the scope of a single transport protocol connection or association. As these QoS-based traffic classes receive different network QoS treatments, they use different pools of network resources and hence may exhibit different levels of congestion. The result for congestion-controlled protocols is that a separate instance of congestion control functionality is needed per QoS-based traffic class. Current transport protocols support only a single instance of congestion control functionality for an entire connection or association; extending that support to multiple instances would add significant protocol complexity. Traffic in different QoS-based classes may use different paths through the network; this complicates path integrity checking in connection- or association-based protocols, as those paths may fail independently.
並べ替えを可能にするPHBが単一のネットワーク5タプル内に混在する場合、単一のトランスポートプロトコル接続または関連付けのスコープ内でQoSベースのトラフィッククラスが混在することになります。これらのQoSベースのトラフィッククラスは異なるネットワークQoS処理を受け取るため、ネットワークリソースの異なるプールを使用するため、異なるレベルの輻輳を示す可能性があります。輻輳制御プロトコルの結果として、QoSベースのトラフィッククラスごとに、輻輳制御機能の個別のインスタンスが必要になります。現在のトランスポートプロトコルは、接続または関連付け全体の輻輳制御機能の単一インスタンスのみをサポートしています。そのサポートを複数のインスタンスに拡張すると、プロトコルが大幅に複雑になります。異なるQoSベースのクラスのトラフィックは、ネットワークを介して異なるパスを使用する場合があります。これらのパスは独立して失敗する可能性があるため、これは接続ベースまたはアソシエーションベースのプロトコルでのパス整合性チェックを複雑にします。
The primary example where usage of multiple PHBs does not enable reordering within a single network 5-tuple is use of PHBs from a single AF class (e.g., AF1x). Traffic reordering within the scope of a network 5-tuple that uses a single PHB or AF class may occur for other transient reasons (e.g., routing changes or ECMP rebalancing).
複数のPHBを使用しても単一のネットワーク5タプル内での並べ替えが有効にならない主な例は、単一のAFクラス（AF1xなど）からのPHBの使用です。単一のPHBまたはAFクラスを使用するネットワーク5タプルのスコープ内でのトラフィックの並べ替えは、他の一時的な理由（ルーティングの変更やECMP再バランシングなど）で発生する場合があります。
Reordering also affects other forms of congestion control, such as techniques for RTP congestion control that were under development when this memo was published; see [RMCAT-CC] for requirements. These techniques prefer use of a common (coupled) congestion controller for RTP streams between the same endpoints to reduce packet loss and delay by reducing competition for resources at any shared bottleneck.
並べ替えは、このメモが発行されたときに開発中だったRTP輻輳制御の手法など、他の形式の輻輳制御にも影響します。要件については、[RMCAT-CC]を参照してください。これらの手法では、共有エンドポイントでのリソースの競合を減らすことにより、パケットの損失と遅延を減らすために、同じエンドポイント間のRTPストリームに共通の（結合された）輻輳コントローラーの使用を優先します。
Shared bottlenecks can be detected via techniques such as correlation of one-way delay measurements across RTP streams. An alternate approach is to assume that the set of packets on a single network 5-tuple marked with DSCPs that do not enable reordering will utilize a common network path and common forwarding resources at each network node. Under that assumption, any bottleneck encountered by such packets is shared among all of them, making it safe to use a common (coupled) congestion controller (see [COUPLED-CC]). This is not a safe assumption when the packets involved are marked with DSCP values that enable reordering because a bottleneck may not be shared among all such packets (e.g., when the DSCP values result in use of different queues at a network node, but only one queue is a bottleneck).
共有ボトルネックは、RTPストリーム全体の一方向遅延測定値の相関などの手法で検出できます。別のアプローチは、並べ替えを有効にしないDSCPでマークされた単一のネットワーク5タプル上のパケットのセットが、各ネットワークノードで共通のネットワークパスと共通の転送リソースを利用すると想定することです。その仮定の下で、そのようなパケットが遭遇するボトルネックはすべてのパケットで共有され、共通の（結合された）輻輳コントローラーを安全に使用できます（[COUPLED-CC]を参照）。これは、関係するパケットが再順序付けを可能にするDSCP値でマークされている場合は安全な仮定ではありません。たとえば、ボトルネックがそのようなすべてのパケット間で共有されない可能性があるためです（たとえば、DSCP値によってネットワークノードで異なるキューが1つだけ使用される場合キューがボトルネックです）。
UDP and UDP-Lite are not sensitive to reordering in the network, because they do not provide reliable delivery or congestion control. On the other hand, when used to encapsulate other protocols (e.g., as UDP is used by WebRTC; see Section 2.1), the reordering considerations for the encapsulated protocols apply. For the specific usage of UDP by WebRTC, every encapsulated protocol (i.e., RTP, SCTP, and TCP) is sensitive to reordering as further discussed in this memo. In addition, [RFC5405] provides general guidelines for use of UDP (and UDP-Lite); the congestion control guidelines in that document apply to protocols encapsulated in UDP (or UDP-Lite).
UDPおよびUDP-Liteは、信頼性の高い配信または輻輳制御を提供しないため、ネットワークでの並べ替えの影響を受けません。一方、他のプロトコルのカプセル化に使用する場合（たとえば、UDPはWebRTCで使用されるため、セクション2.1を参照）、カプセル化されたプロトコルの並べ替えに関する考慮事項が適用されます。 WebRTCによるUDPの特定の使用法では、すべてのカプセル化されたプロトコル（つまり、RTP、SCTP、およびTCP）は、このメモでさらに説明されているように、並べ替えの影響を受けます。さらに、[RFC5405]はUDP（およびUDP-Lite）の使用に関する一般的なガイドラインを提供します。そのドキュメントの輻輳制御ガイドラインは、UDP（またはUDP-Lite）でカプセル化されたプロトコルに適用されます。
Real-time communications are also sensitive to network reordering of packets. Such reordering may lead to unneeded retransmission and spurious retransmission control signals (such as NACK) in reliable delivery protocols (see Section 5.1). The degree of sensitivity depends on protocol or stream timers, in contrast to reliable delivery protocols that usually react to all reordering.
リアルタイム通信は、パケットのネットワーク並べ替えの影響も受けます。このような並べ替えは、信頼性の高い配信プロトコル（セクション5.1を参照）で、不要な再送信と偽の再送信制御信号（NACKなど）につながる可能性があります。感度の程度は、通常すべての並べ替えに反応する信頼性の高い配信プロトコルとは対照的に、プロトコルまたはストリームタイマーに依存します。
Receiver jitter buffers have important roles in the effect of reordering on real-time communications:
レシーバーのジッターバッファーは、リアルタイム通信での並べ替えの効果に重要な役割を果たします。
o Minor packet reordering that is contained within a jitter buffer usually has no effect on rendering of the received RTP stream because packets that arrive out of order are retrieved in order from the jitter buffer for rendering.
o ジッタバッファ内に含まれる小さなパケットの並べ替えは、通常、受信したRTPストリームのレンダリングに影響を与えません。これは、順不同で到着したパケットがジッタバッファから順番に取得されてレンダリングされるためです。
o Packet reordering that exceeds the capacity of a jitter buffer can cause user-perceptible quality problems (e.g., glitches, noise) for delay-sensitive communication, such as interactive conversations for which small jitter buffers are necessary to preserve human perceptions of real-time interaction. Interactive real-time communication implementations often discard data that is sufficiently late so that it cannot be rendered in source stream order, making retransmission counterproductive. For this reason, implementations of interactive real-time communication often do not use retransmission.
o ジッタバッファの容量を超えるパケットの並べ替えは、リアルタイムインタラクションの人間の認識を維持するために小さなジッタバッファが必要なインタラクティブな会話など、遅延の影響を受けやすい通信で、ユーザーに知覚可能な品質の問題（グリッチ、ノイズなど）を引き起こす可能性があります。 。インタラクティブなリアルタイム通信の実装では、ソースストリームの順序でレンダリングできないように十分に遅いデータが破棄されることが多く、再送信の逆効果になります。このため、インタラクティブなリアルタイム通信の実装では、再送信を使用しないことがよくあります。
o In contrast, replay of recorded media can tolerate significantly longer delays than interactive conversations, so replay is likely to use larger jitter buffers than interactive conversations. These larger jitter buffers increase the tolerance of replay to reordering by comparison to interactive conversations. The size of the jitter buffer imposes an upper bound on replay tolerance to reordering but does enable retransmission to be used when the jitter buffer is significantly larger than the amount of data that can be expected to arrive during the round-trip latency for retransmission.
o対照的に、記録されたメディアの再生は、インタラクティブな会話よりも大幅に長い遅延を許容できるため、再生ではインタラクティブな会話よりも大きなジッターバッファーを使用する可能性があります。これらのより大きなジッターバッファーは、対話型の会話と比較して、並べ替えに対する再生の許容度を高めます。ジッタバッファのサイズは、リオーダリングの再生許容値に上限を課しますが、ジッタバッファが再送のラウンドトリップレイテンシ中に到着することが予想されるデータの量よりも大幅に大きい場合に、再送を使用できるようにします。
Network packet reordering has no effective upper bound and can exceed the size of any reasonable jitter buffer. In practice, the size of jitter buffers for replay is limited by external factors such as the amount of time that a human is willing to wait for replay to start.
ネットワークパケットの並べ替えには有効な上限がなく、妥当なジッタバッファのサイズを超える可能性があります。実際には、再生用のジッタバッファのサイズは、人間が再生の開始を待機する用意がある時間などの外部要因によって制限されます。
Packets within the same network 5-tuple that use PHBs within a single AF class can be expected to draw upon the same forwarding resources on network nodes (e.g., use the same router queue), and hence use of multiple drop precedences within an AF class is not expected to cause latency variation. When PHBs within a single AF class are mixed within a flow, the resulting overall likelihood that packets will be dropped from that flow is a mix of the drop likelihoods of the PHBs involved.
単一のAFクラス内でPHBを使用する同じネットワーク5タプル内のパケットは、ネットワークノード上の同じ転送リソースを使用する（たとえば、同じルーターキューを使用する）ことが予想され、したがって、AFクラス内で複数のドロップ優先順位を使用します。レイテンシの変動が発生することは想定されていません。単一のAFクラス内のPHBがフロー内で混在している場合、そのフローからパケットがドロップされる全体的な可能性は、関係するPHBのドロップ可能性の混合です。
There are situations in which drop precedences should not be mixed. A simple example is that there is little value in mixing drop precedences within a TCP connection, because TCP's ordered delivery behavior results in any drop requiring the receiver to wait for the dropped packet to be retransmitted. Any resulting delay depends on the RTT and not the packet that was dropped. Hence a single DSCP should be used for all packets in a TCP connection.
ドロップの優先順位を混合してはならない状況があります。単純な例は、TCP接続内でドロップの優先順位を混在させることにほとんど価値がないことです。これは、TCPの順序付けされた配信動作により、ドロップが発生し、ドロップされたパケットが再送信されるまでレシーバーが待機する必要があるためです。結果として生じる遅延は、RTTに依存し、ドロップされたパケットには依存しません。したがって、TCP接続のすべてのパケットに単一のDSCPを使用する必要があります。
As a consequence, when TCP is selected for NAT/FW traversal (e.g., by TURN), a single DSCP should be used for all traffic on that TCP connection. An additional reason for this recommendation is that packetization for STUN/ICE/TURN occurs before passing the resulting packets to TCP; TCP resegmentation may result in a different packetization on the wire, breaking any association between DSCPs and specific data to which they are intended to apply.
その結果、NAT / FWトラバーサルにTCPが選択された場合（TURNなど）、そのTCP接続のすべてのトラフィックに単一のDSCPを使用する必要があります。この推奨事項のもう1つの理由は、STUN / ICE / TURNのパケット化が、結果のパケットをTCPに渡す前に発生することです。 TCP再分割により、回線上で異なるパケット化が発生し、DSCPとそれらが適用される特定のデータとの間の関連付けが失われる可能性があります。
SCTP [RFC4960] differs from TCP in a number of ways, including the ability to deliver messages in an order that differs from the order in which they were sent and support for unreliable streams. However, SCTP performs congestion control and retransmission across the entire association, and not on a per-stream basis. Although there may be advantages to using multiple drop precedence across SCTP streams or within an SCTP stream that does not use reliable ordered delivery, there is no practical operational experience in doing so (e.g., the SCTP sockets API [RFC6458] does not support use of more than one DSCP for an SCTP association). As a consequence, the impacts on SCTP protocol and implementation behavior are unknown and difficult to predict. Hence a single DSCP should be used for all packets in an SCTP association, independent of the number or nature of streams in that association. Similar reasoning applies to a DCCP connection; a single DSCP should be used because the scope of congestion control is the connection and there is no operational experience with using more than one DSCP. This recommendation may be revised in the future if experiments, analysis, and operational experience provide compelling reasons to change it.
SCTP [RFC4960]は、メッセージが送信された順序とは異なる順序でメッセージを配信する機能や信頼性の低いストリームのサポートなど、さまざまな点でTCPとは異なります。ただし、SCTPは、ストリームごとではなく、アソシエーション全体で輻輳制御と再送信を実行します。 SCTPストリーム全体またはSCTPストリーム内で信頼性の高い順序付けされた配信を使用しない複数のドロップ優先順位を使用することには利点があるかもしれませんが、実際の運用経験はありません（たとえば、SCTPソケットAPI [RFC6458]は、 SCTPアソシエーションの複数のDSCP）。その結果、SCTPプロトコルと実装の動作への影響は不明であり、予測が困難です。したがって、SCTPアソシエーションのストリームの数や性質に関係なく、SCTPアソシエーションのすべてのパケットに単一のDSCPを使用する必要があります。同様の理由がDCCP接続にも当てはまります。輻輳制御の範囲は接続であり、複数のDSCPを使用した運用経験がないため、単一のDSCPを使用する必要があります。この推奨事項は、実験、分析、および運用上の経験から、それを変更する説得力のある理由が提供された場合、将来改訂される可能性があります。
Guidance on transport protocol design and implementation to provide support for use of multiple PHBs and DSCPs in a transport protocol connection (e.g., DCCP) or transport protocol association (e.g., SCTP) is out of scope for this memo.
トランスポートプロトコル接続（DCCPなど）またはトランスポートプロトコルアソシエーション（SCTPなど）での複数のPHBおよびDSCPの使用をサポートするためのトランスポートプロトコルの設計と実装に関するガイダンスは、このメモの範囲外です。
RTCP [RFC3550] is used with RTP to monitor quality of service and convey information about RTP session participants. A sender of RTCP packets that also sends RTP packets (i.e., originates an RTP stream) should use the same DSCP marking for both types of packets. If an RTCP sender doesn't send any RTP packets, it should mark its RTCP packets with the DSCP that it would use if it did send RTP packets with media similar to the RTP traffic that it receives. If the RTCP sender uses or would use multiple DSCPs that differ only in drop precedence for RTP, then it should use the DSCP with the least likelihood of drop for RTCP to increase the likelihood of RTCP packet delivery.
RTCP [RFC3550]はRTPと共に使用され、サービス品質を監視し、RTPセッション参加者に関する情報を伝えます。 RTPパケットも送信する（つまり、RTPストリームを発信する）RTCPパケットの送信者は、両方のタイプのパケットに同じDSCPマーキングを使用する必要があります。 RTCP送信者がRTPパケットを送信しない場合は、受信したRTPトラフィックと同様のメディアを含むRTPパケットを送信した場合に使用するDSCPでRTCPパケットをマークする必要があります。 RTCP送信者がRTPのドロップ優先順位のみが異なる複数のDSCPを使用するか使用する場合、RTCPのドロップの可能性が最も低いDSCPを使用して、RTCPパケット配信の可能性を高める必要があります。
If the SDP bundle extension [SDP-BUNDLE] is used to negotiate sending multiple types of media in a single RTP session, then receivers will send separate RTCP reports for each type of media, using a separate SSRC for each media type; each RTCP report should be marked with the DSCP corresponding to the type of media handled by the reporting SSRC.
SDPバンドル拡張[SDP-BUNDLE]を使用して単一のRTPセッションで複数のタイプのメディアの送信をネゴシエートする場合、受信者はメディアタイプごとに個別のSSRCを使用して、メディアタイプごとに個別のRTCPレポートを送信します。各RTCPレポートは、レポートSSRCによって処理されるメディアのタイプに対応するDSCPでマークする必要があります。
This guidance may result in different DSCP markings for RTP streams and RTCP receiver reports about those RTP streams. The resulting variation in network QoS treatment by traffic direction is necessary to obtain representative round-trip time (RTT) estimates that correspond to the media path RTT, which may differ from the transport protocol RTT. RTCP receiver reports may be relatively infrequent, and hence the resulting RTT estimates are of limited utility for transport protocol congestion control (although those RTT estimates have other important uses; see [RFC3550]). For this reason, it is important that RTCP receiver reports sent by an SSRC receive the same network QoS treatment as the RTP stream being sent by that SSRC.
このガイダンスにより、RTPストリームとそれらのRTPストリームに関するRTCP受信者レポートのDSCPマーキングが異なる場合があります。トラフィック方向によるネットワークQoS処理の結果として生じる変動は、トランスポートプロトコルRTTとは異なる可能性があるメディアパスRTTに対応する代表的なラウンドトリップ時間（RTT）推定値を取得するために必要です。 RTCP受信者レポートは比較的まれである可能性があるため、結果として得られるRTT推定は、トランスポートプロトコルの輻輳制御には限られた有用性しかありません（これらのRTT推定には他の重要な用途があります。[RFC3550]を参照）。このため、SSRCによって送信されたRTCP受信者レポートが、そのSSRCによって送信されているRTPストリームと同じネットワークQoS処理を受信することが重要です。
The only use of multiple standardized PHBs and DSCPs that does not enable network reordering among packets marked with different DSCPs is use of PHBs within a single AF class. All other uses of multiple PHBs and/or the class selector DSCPs enable network reordering of packets that are marked with different DSCPs. Based on this and the foregoing discussion, the guidelines in this section apply to use of Diffserv with real-time communications.
異なるDSCPでマークされたパケット間のネットワークの並べ替えを有効にしない複数の標準化されたPHBおよびDSCPの唯一の使用法は、単一のAFクラス内のPHBの使用です。複数のPHBやクラスセレクタDSCPの他のすべての使用は、異なるDSCPでマークされたパケットのネットワークの並べ替えを可能にします。これと前述の説明に基づいて、このセクションのガイドラインは、リアルタイム通信でのDiffservの使用に適用されます。
Applications and other traffic sources (including RTP SSRCs):
アプリケーションおよびその他のトラフィックソース（RTP SSRCを含む）：
o Should limit use of DSCPs within a single RTP stream to those whose corresponding PHBs do not enable packet reordering. If this is not done, significant network reordering may overwhelm implementation assumptions about reordering limits, e.g., jitter buffer size, causing poor user experiences (see Section 5.2). This guideline applies to all of the RTP streams that are within the scope of a common (coupled) congestion controller when that controller does not use per-RTP-stream measurements for bottleneck detection.
o 単一のRTPストリーム内のDSCPの使用を、対応するPHBがパケットの並べ替えを有効にしないものに制限する必要があります。これを行わないと、ジッターバッファーサイズなど、並べ替えの制限に関する実装の仮定がネットワークの大幅な並べ替えによって圧倒され、ユーザーエクスペリエンスが低下する可能性があります（セクション5.2を参照）。このガイドラインは、コントローラーがボトルネック検出にRTPストリームごとの測定を使用しない場合、一般的な（結合された）輻輳コントローラーの範囲内にあるすべてのRTPストリームに適用されます。
o Should use a single DSCP for RTCP packets, which should be a DSCP used for RTP packets that are or would be sent by that SSRC (see Section 5.4).
o RTCPパケットに単一のDSCPを使用する必要があります。これは、そのSSRCによって送信される、または送信されるRTPパケットに使用されるDSCPである必要があります（セクション5.4を参照）。
o Should use a single DSCP for all packets within a reliable transport protocol session (e.g., TCP connection, SCTP association) or DCCP connection (see Sections 5.1 and 5.3). For SCTP, this requirement applies across the entire SCTP association, and not just to individual streams within an association. When TURN selects TCP for NAT/FW traversal, this guideline applies to all traffic multiplexed onto that TCP connection, in contrast to use of UDP for NAT/FW traversal.
o 信頼できるトランスポートプロトコルセッション（TCP接続、SCTPアソシエーションなど）またはDCCP接続（セクション5.1および5.3を参照）内のすべてのパケットに単一のDSCPを使用する必要があります。 SCTPの場合、この要件は、アソシエーション内の個々のストリームだけでなく、SCTPアソシエーション全体に適用されます。 TURNがNAT / FWトラバーサルにTCPを選択すると、このガイドラインは、NAT / FWトラバーサルにUDPを使用するのとは対照的に、そのTCP接続に多重化されたすべてのトラフィックに適用されます。
o May use different DSCPs whose corresponding PHBs enable reordering within a single UDP or UDP-Lite 5-tuple, subject to the above constraints. The service differentiation provided by such usage is unreliable, as it may be removed or changed by DSCP remarking at network boundaries as described in Section 3.2 above.
o 上記の制約に従い、対応するPHBが単一のUDPまたはUDP-Lite 5タプル内での並べ替えを可能にするさまざまなDSCPを使用できます。上記のセクション3.2で説明したように、ネットワーク境界でのDSCP再マーキングによって削除または変更される可能性があるため、このような使用法によって提供されるサービスの差別化は信頼できません。
o Cannot rely on end-to-end preservation of DSCPs as network node remarking can change DSCPs and remove drop precedence distinctions (see Section 3.2). For example, if a source uses drop precedence distinctions within an AF class to identify different types of video frames, using those DSCP values at the receiver to identify frame type is inherently unreliable.
o ネットワークノードの再マーキングによりDSCPが変更され、ドロップ優先順位の違いが削除される可能性があるため（セクション3.2を参照）、DSCPのエンドツーエンドの保持に依存することはできません。たとえば、ソースがAFクラス内でドロップ優先順位の区別を使用してさまざまなタイプのビデオフレームを識別する場合、受信側でそれらのDSCP値を使用してフレームタイプを識別することは本質的に信頼できません。
o Should limit use of the CS1 codepoint to traffic for which best effort forwarding is acceptable, as network support for use of CS1 to select a "less than best-effort" PHB is inconsistent. Further, some networks may treat CS1 as providing "better than best-effort" forwarding behavior.
o 「ベストエフォート未満」のPHBを選択するためのCS1の使用に対するネットワークサポートに一貫性がないため、CS1コードポイントの使用を、ベストエフォート転送が許容されるトラフィックに制限する必要があります。さらに、一部のネットワークでは、CS1を「ベストエフォートよりも優れた」転送動作を提供するものとして扱う場合があります。
There is no guidance in this memo on how network operators should differentiate traffic. Networks may support all of the PHBs discussed herein, classify EF and AFxx traffic identically, or even remark all traffic to best effort at some ingress points. Nonetheless, it is useful for applications and other traffic sources to provide finer granularity DSCP marking on packets for the benefit of networks that offer QoS service differentiation. A specific example is that traffic originating from a browser may benefit from QoS service differentiation in within-building and residential access networks, even if the DSCP marking is subsequently removed or simplified. This is because such networks and the boundaries between them are likely traffic bottleneck locations (e.g., due to customer aggregation onto common links and/or speed differences among links used by the same traffic).
このメモには、ネットワークオペレーターがトラフィックをどのように差別化するかについてのガイダンスはありません。ネットワークは、ここで説明するすべてのPHBをサポートし、EFトラフィックとAFxxトラフィックを同一に分類するか、すべてのトラフィックをいくつかの入口ポイントでベストエフォートにマークします。それにもかかわらず、QoSサービスの差別化を提供するネットワークの利益のために、アプリケーションや他のトラフィックソースがパケットにより細かい粒度のDSCPマーキングを提供することは有用です。特定の例は、DSCPマーキングが後で削除または簡略化された場合でも、ブラウザーから発信されるトラフィックは、建物内および住宅用アクセスネットワークでQoSサービスの差別化の恩恵を受ける可能性があることです。これは、そのようなネットワークとそれらの間の境界が、トラフィックのボトルネックになる可能性があるためです（たとえば、顧客が共通リンクに集約したり、同じトラフィックで使用されるリンク間の速度が異なったりするため）。
The security considerations for all of the technologies discussed in this memo apply; in particular, see the security considerations for RTP in [RFC3550] and Diffserv in [RFC2474] and [RFC2475].
このメモで説明されているすべてのテクノロジのセキュリティに関する考慮事項が適用されます。特に、[RFC3550]のRTPおよび[RFC2474]と[RFC2475]のDiffservのセキュリティに関する考慮事項を参照してください。
Multiplexing of multiple protocols onto a single UDP 5-tuple via encapsulation has implications for network functionality that monitors or inspects individual protocol flows, e.g., firewalls and traffic monitoring systems. When implementations of such functionality lack visibility into encapsulated traffic (likely for many current implementations), it may be difficult or impossible to apply network security policy and associated controls at a finer granularity than the overall UDP 5-tuple.
カプセル化による複数のプロトコルの単一のUDP 5タプルへの多重化は、ファイアウォールやトラフィック監視システムなど、個々のプロトコルフローを監視または検査するネットワーク機能に影響を与えます。そのような機能の実装がカプセル化されたトラフィックの可視性を欠いている場合（現在の多くの実装の可能性があります）、ネットワークセキュリティポリシーと関連するコントロールを、UDP 5タプル全体よりも細かく適用することは困難または不可能です。
Use of multiple DSCPs that enable reordering within an overall real-time communication interaction enlarges the set of network forwarding resources used by that interaction, thereby increasing exposure to resource depletion or failure, independent of whether the underlying cause is benign or malicious. This represents an increase in the effective attack surface of the interaction and is a consideration in selecting an appropriate degree of QoS differentiation among the components of the real-time communication interaction. See Section 3.3.2.1 of [RFC6274] for related discussion of DSCP security considerations.
全体的なリアルタイム通信相互作用内での並べ替えを可能にする複数のDSCPを使用すると、その相互作用によって使用されるネットワーク転送リソースのセットが拡大し、根本的な原因が良性か悪意かに関係なく、リソースの枯渇または障害の危険性が高まります。これは、相互作用の効果的な攻撃面の増加を表し、リアルタイム通信相互作用のコンポーネント間のQoSの差別化の適切な程度を選択する際の考慮事項です。 DSCPのセキュリティに関する考慮事項については、[RFC6274]のセクション3.3.2.1を参照してください。
Use of multiple DSCPs to provide differentiated QoS service may reveal information about the encrypted traffic to which different service levels are provided. For example, DSCP-based identification of RTP streams combined with packet frequency and packet size could reveal the type or nature of the encrypted source streams. The IP header used for forwarding has to be unencrypted for obvious reasons, and the DSCP likewise has to be unencrypted to enable different IP forwarding behaviors to be applied to different packets. The nature of encrypted traffic components can be disguised via encrypted dummy data padding and encrypted dummy packets, e.g., see the discussion of traffic flow confidentiality in [RFC4303]. Encrypted dummy packets could even be added in a fashion that an observer of the overall encrypted traffic might mistake for another encrypted RTP stream.
複数のDSCPを使用して差別化されたQoSサービスを提供すると、異なるサービスレベルが提供されている暗号化されたトラフィックに関する情報が明らかになる場合があります。たとえば、RTPストリームのDSCPベースの識別とパケット頻度およびパケットサイズを組み合わせると、暗号化されたソースストリームのタイプまたは性質が明らかになる可能性があります。転送に使用されるIPヘッダーは明らかな理由で暗号化解除する必要があり、DSCPも同様に暗号化解除して、異なるIP転送動作を異なるパケットに適用できるようにする必要があります。暗号化されたトラフィックコンポーネントの性質は、暗号化されたダミーデータパディングと暗号化されたダミーパケットを介して偽装することができます。たとえば、[RFC4303]のトラフィックフローの機密性に関する説明を参照してください。暗号化されたダミーパケットは、暗号化されたトラフィック全体の監視者が別の暗号化されたRTPストリームと間違えるような方法で追加することもできます。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[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, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<http://www.rfc-editor.org/info/rfc2474>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<http://www.rfc-editor.org/info/rfc2475>。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <http://www.rfc-editor.org/info/rfc2597>.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、DOI 10.17487 / RFC2597、1999年6月、<http：//www.rfc- editor.org/info/rfc2597>。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <http://www.rfc-editor.org/info/rfc3246>.
[RFC3246]デイビー、B、チャーニー、A、ベネット、J、ベンソン、K、ルブーデック、J、コートニー、W、ダヴァリ、S、フィロイ、V、およびDスティリアディス、 Expedited Forwarding PHB（Per-Hop Behavior）」、RFC 3246、DOI 10.17487 / RFC3246、2002年3月、<http://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, <http://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月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <http://www.rfc-editor.org/info/rfc3662>.
[RFC3662] Bless、R.、Nichols、K。、およびK. Wehrle、「Differentiated Servicesのドメインごとの動作（PDB）の削減」、RFC 3662、DOI 10.17487 / RFC3662、2003年12月、<http：// www.rfc-editor.org/info/rfc3662>。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828] Larzon、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 DOI 10.17487 / RFC3828、2004年7月、<http://www.rfc-editor.org/info/rfc3828>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<http：//www.rfc-editor。 org / info / rfc4340>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<http://www.rfc-editor.org/info/rfc4960>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、DOI 10.17487 / RFC5405、2008年11月、<http://www.rfc-editor.org/info / rfc5405>。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <http://www.rfc-editor.org/info/rfc5865>.
[RFC5865]ベイカー、F。、ポーク、J。、およびM.ドリー、「Capacity-Admitted TrafficのDiffServコードポイント（DSCP）」、RFC 5865、DOI 10.17487 / RFC5865、2010年5月、<http：// www.rfc-editor.org/info/rfc5865>。
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <http://www.rfc-editor.org/info/rfc6951>.
[RFC6951] Tuexen、M。、およびR. Stewart、「エンドホストからエンドホストへの通信用のストリーム制御伝送プロトコル（SCTP）パケットのUDPカプセル化」、RFC 6951、DOI 10.17487 / RFC6951、2013年5月、<http：/ /www.rfc-editor.org/info/rfc6951>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for the Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「リアルタイム転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」 、RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<http://www.rfc-editor.org/info/rfc7656>。
[COUPLED-CC] Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion control for RTP media", Work in Progress, draft-welzl-rmcat-coupled-cc-05, June 2015.
[COUPLED-CC] Welzl、M.、Islam、S。、およびS. Gjessing、「RTPメディアの結合された輻輳制御」、Work in Progress、draft-welzl-rmcat-coupled-cc-05、2015年6月。
[DATA-CHAN] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", Work in Progress, draft-ietf-rtcweb-data-channel-13, January 2015.
[DATA-CHAN] Jesup、R.、Loreto、S。、およびM. Tuexen、「WebRTCデータチャネル」、Work in Progress、draft-ietf-rtcweb-data-channel-13、2015年1月。
[DIFFSERV-INTERCON] Geib, R., Ed. and D. Black, "Diffserv interconnection classes and practice", Work in Progress, draft-ietf-tsvwg-diffserv-intercon-03, October 2015.
[DIFFSERV-INTERCON]ガイブ、R。、エド。 D.ブラック、「Diffserv相互接続クラスと実践」、Work in Progress、draft-ietf-tsvwg-diffserv-intercon-03、2015年10月。
[H.221] ITU-T, "Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices", Recommendation H.221, March 2009.
[H.221] ITU-T、「オーディオビジュアルテレサービスにおける64〜1920 kbit / sチャネルのフレーム構造」、勧告H.221、2009年3月。
[H.264] ITU-T, "Advanced video coding for generic audiovisual services", Recommendation H.264, February 2014.
[H.264] ITU-T、「Advanced audiocoding for generic audiovisual services」、Recommendation H.264、2014年2月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, <http://www.rfc-editor.org/info/rfc2697>.
[RFC2697] Heinanen、J。およびR. Guerin、「A Single Rate Three Color Marker」、RFC 2697、DOI 10.17487 / RFC2697、1999年9月、<http://www.rfc-editor.org/info/rfc2697>。
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, <http://www.rfc-editor.org/info/rfc2698>.
[RFC2698] Heinanen、J。およびR. Guerin、「A Two Rate Three Color Marker」、RFC 2698、DOI 10.17487 / RFC2698、1999年9月、<http://www.rfc-editor.org/info/rfc2698>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914] Floyd、S。、「Congestion Control Principles」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<http://www.rfc-editor.org/info/rfc2914>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, <http://www.rfc-editor.org/info/rfc3270>.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J. Heinanen、 "マルチプロトコルラベルスイッチング（MPLS）Support of Differentiated Services」、RFC 3270、DOI 10.17487 / RFC3270、2002年5月、<http://www.rfc-editor.org/info/rfc3270>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <http://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G。およびP. Jones、「RTP Payload for Text Conversation」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<http://www.rfc-editor.org/info/rfc4103>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://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月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<http://www.rfc-editor.org / info / rfc4594>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<http://www.rfc-editor.org/info/rfc5109> 。
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[RFC5127] Chan、K.、Babiarz、J。、およびF. Baker、「Aggregation of Diffserv Service Classes」、RFC 5127、DOI 10.17487 / RFC5127、2008年2月、<http://www.rfc-editor.org/ info / rfc5127>。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC5129]デイビー、B。、ブリスコー、B。、およびJ.テイ、「MPLSでの明示的輻輳マーキング」、RFC 5129、DOI 10.17487 / RFC5129、2008年1月、<http://www.rfc-editor.org/ info / rfc5129>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <http://www.rfc-editor.org/info/rfc5462>.
[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Renamed to "Traffic Class" Field」、RFC 5462、DOI 10.17487 / RFC5462、2009年2月、<http： //www.rfc-editor.org/info/rfc5462>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C。およびM. Westerlund、「Multiplexing RTP Data and Control Packets on a Single Port」、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<http://www.rfc-editor.org/info / rfc5761>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <http://www.rfc-editor.org/info/rfc5764>.
[RFC5764] McGrew、D。およびE. Rescorla、「Secure Real-time Transport Protocol（SRTP）のキーを確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張」、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<http ：//www.rfc-editor.org/info/rfc5764>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P.、J。Rosenberg、「NAT（TURN）のリレーを使用したトラバーサル：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<http://www.rfc-editor.org/info/rfc5766>。
[RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, DOI 10.17487/RFC6062, November 2010, <http://www.rfc-editor.org/info/rfc6062>.
[RFC6062] Perreault、S.、Ed。およびJ. Rosenberg、「TCP割り当てのためのNAT（TURN）拡張の周りのリレーを使用したトラバーサル」、RFC 6062、DOI 10.17487 / RFC6062、2010年11月、<http://www.rfc-editor.org/info/rfc6062>。
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, <http://www.rfc-editor.org/info/rfc6274>.
[RFC6274] Gont、F。、「インターネットプロトコルバージョン4のセキュリティ評価」、RFC 6274、DOI 10.17487 / RFC6274、2011年7月、<http://www.rfc-editor.org/info/rfc6274>。
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, <http://www.rfc-editor.org/info/rfc6386>.
[RFC6386] Bankoski、J.、Koleszar、J.、Quillio、L.、Salonen、J.、Wilkins、P.、and Y. Xu、 "VP8 Data Format and Decoding Guide"、RFC 6386、DOI 10.17487 / RFC6386、 2011年11月、<http://www.rfc-editor.org/info/rfc6386>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<http：//www.rfc- editor.org/info/rfc6437>。
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <http://www.rfc-editor.org/info/rfc6458>.
[RFC6458] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Socket Control Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、DOI 10.17487 / RFC6458 、2011年12月、<http://www.rfc-editor.org/info/rfc6458>。
[RMCAT-CC] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", Work in Progress, draft-ietf-rmcat-cc-requirements-09, December 2014.
[RMCAT-CC] Jesup、R。およびZ. Sarker、「インタラクティブリアルタイムメディアの輻輳制御要件」、作業中、draft-ietf-rmcat-cc-requirements-09、2014年12月。
[RTP-USAGE] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Work in Progress, draft-ietf-rtcweb-rtp-usage-25, June 2015.
[RTP-USAGE] Perkins、C.、Westerlund、M。、およびJ. Ott、「Webリアルタイム通信（WebRTC）：Media Transport and Use of RTP」、Work in Progress、draft-ietf-rtcweb-rtp- 2015年6月25日使用。
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-23, July 2015.
[SDP-BUNDLE] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「Session Description Protocol（SDP）を使用したメディア多重化のネゴシエーション」、進行中の作業、draft-ietf-mmusic-sdp-bundle-negotiation- 2015年7月23日。
[SRTP-DTLS] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", Work in Progress, draft-petithuguenin-avtcore-rfc5764-mux-fixes-02, March 2015.
[SRTP-DTLS] Petit-Huguenin、M。、およびG. Salgueiro、「データグラムトランスポート層セキュリティ（DTLS）のセキュアリアルタイムトランスポートプロトコル（SRTP）拡張のための多重化スキームの更新」、作業中、draft-petithuguenin-avtcore -rfc5764-mux-fixes-02、2015年3月。
[W3C.WD-mediacapture-streams-20130903] Burnett, D., Bergkvist, A., Jennings, C., and A. Narayanan, "Media Capture and Streams", World Wide Web Consortium Recommendation WD-mediacapture-streams-20130903, September 2013, <http://www.w3.org/TR/2013/ WD-mediacapture-streams-20130903>.
[W3C.WD-mediacapture-streams-20130903]バーネット、D。、バーグビスト、A。、ジェニングス、C。、およびA.ナラヤナン、「メディアキャプチャおよびストリーム」、World Wide Web Consortium Recommendation WD-mediacapture-streams-20130903 、2013年9月、<http://www.w3.org/TR/2013/ WD-mediacapture-streams-20130903>。
[WEBRTC-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-14, June 2015.
[WEBRTC-OVERVIEW] Alvestrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-ietf-rtcweb-overview-14、June 2015。
[WEBRTC-TRANSPORTS] Alvestrand, H., "Transports for WebRTC", Work in Progress, draft-ietf-rtcweb-transports-10, October 2015.
[WEBRTC-TRANSPORTS] Alvestrand、H。、「Transports for WebRTC」、Work in Progress、draft-ietf-rtcweb-transports-10、2015年10月。
Acknowledgements
謝辞
This memo is the result of many conversations that have occurred within the DART working group and other working groups in the RAI and Transport areas. Many thanks to Aamer Akhter, Harald Alvestrand, Fred Baker, Richard Barnes, Erin Bournival, Ben Campbell, Brian Carpenter, Spencer Dawkins, Keith Drage, Gorry Fairhurst, Ruediger Geib, Cullen Jennings, Jonathan Lennox, Karen Nielsen, Colin Perkins, James Polk, Robert Sparks, Tina Tsou, Michael Welzl, Dan York, and the DART WG participants for their reviews and comments.
このメモは、DARTワーキンググループおよびRAIおよびトランスポートエリアの他のワーキンググループ内で行われた多くの会話の結果です。 Aamer Akhter、Harald Alvestrand、Fred Baker、Richard Barnes、Erin Bournival、Ben Campbell、Brian Carpenter、Spencer Dawkins、Keith Drage、Gorry Fairhurst、Ruediger Geib、Cullen Jennings、Jonathan Lennox、Karen Nielsen、Colin Perelins、James Polkに感謝します、Robert Sparks、Tina Tsou、Michael Welzl、Dan York、DART WGの参加者によるレビューとコメント。
Authors' Addresses
著者のアドレス
David Black (editor) EMC 176 South Street Hopkinton, MA 01748 United States
David Black（editor）EMC 176 South Street Hopkinton、MA 01748 United States
Phone: +1 508 293-7953
Email: david.black@emc.com
Paul Jones Cisco 7025 Kit Creek Road Research Triangle Park, NC 27502 United States
ポールジョーンズCisco 7025 Kit Creek Road Research Triangle Park、NC 27502 United States
Phone: +1 919 476 2048
Email: paulej@packetizer.com