<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-tsvwg-rtcweb-qos-18"ipr="trust200902">indexInclude="true" ipr="trust200902" number="8837" prepTime="2021-01-16T23:27:34" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos-18" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8837" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="WebRTCQoS"> DSCPQoS">Differentiated Services Code Point (DSCP) Packet Markings for WebRTCQoS </title>QoS</title> <seriesInfo name="RFC" value="8837" stream="IETF"/> <author fullname="Paul E. Jones" initials="P." surname="Jones"><organization>Cisco<organization showOnFrontPage="true">Cisco Systems</organization> <address> <email>paulej@packetizer.com</email> </address> </author> <author fullname="Subha Dhesikan" initials="S." surname="Dhesikan"><organization>Cisco Systems</organization><organization showOnFrontPage="true">Individual</organization> <address><email>sdhesika@cisco.com</email><email>sdhesikan@gmail.com</email> </address> </author> <author fullname="Cullen Jennings" initials="C." surname="Jennings"><organization>Cisco<organization showOnFrontPage="true">Cisco Systems</organization> <address> <email>fluffy@cisco.com</email> </address> </author> <author fullname="Dan Druta" initials="D." surname="Druta"><organization>AT&T</organization><organization showOnFrontPage="true">AT&T</organization> <address> <email>dd5826@att.com</email> </address> </author><date/> <abstract> <t> Many networks, such as service provider and enterprise networks,<date month="01" year="2021"/> <keyword>Diffserv</keyword> <keyword>rtcweb</keyword> <abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1"> 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 ofWebRTCWeb Real-Time Communication (WebRTC) traffic. </t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t indent="0" pn="section-boilerplate.1-2"> 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. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8837" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-relation-to-other-specifica">Relation to Other Specifications</xref></t> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-inputs">Inputs</xref></t> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-dscp-mappings">DSCP Mappings</xref></t> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.7"> <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-downward-references">Downward References</xref></t> </li> <li pn="section-toc.1-1.9"> <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2"> <li pn="section-toc.1-1.9.2.1"> <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.9.2.2"> <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.11"> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-dedication">Dedication</xref></t> </li> <li pn="section-toc.1-1.12"> <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <sectiontitle="Introduction"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1"> Differentiated Services Code Point (DSCP) <xreftarget="RFC2474"/>target="RFC2474" format="default" sectionFormat="of" derivedContent="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 otherIETFRFCs. The contents of this specification are intended to be a simple set of implementation recommendations based ontheprevious RFCs. </t><t><t indent="0" pn="section-1-2"> Networkswherein which these DSCP markings are beneficial (likely to improve QoS for WebRTC traffic) include: </t><t> <list style="numbers"> <t><ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-3"> <li pn="section-1-3.1" derivedCounter="1."> Private, wide-area networks. Network administrators have control over remarking packets and treatment of packets.</t> <t></li> <li pn="section-1-3.2" derivedCounter="2."> Residential Networks. If the congested link is the broadband uplink in a cable or DSL scenario,oftenresidential routers/NAT often support preferential treatment based on DSCP.</t> <t></li> <li pn="section-1-3.3" derivedCounter="3."> Wireless Networks. If the congested link is a local wireless network, marking may help.</t> </list> </t> <t></li> </ol> <t indent="0" pn="section-1-4"> There are cases where these DSCP markings do nothelp,help but, aside from possible priority inversion for"less than best effort"Less-than-Best-Effort traffic" (seeSection 5),<xref target="dscp-mappings" format="default" sectionFormat="of" derivedContent="Section 5"/>), they seldom make things worse if packets are marked appropriately. </t><t><t indent="0" pn="section-1-5"> DSCP valuesareare, inprincipleprinciple, sitespecific,specific with each site selecting its own code points for controllingper-hop-behaviorper-hop behavior to influence the QoS for transport-layer flows.HoweverHowever, in the WebRTC use cases, the browsers need to set them to something when there is nosite specificsite-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 isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that WebRTC applications use non-default values only in private networks that are configured to use different values. </t><t><t indent="0" pn="section-1-6"> 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. </t> </section> <sectiontitle="Terminology"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-terminology">Terminology</name> <t indent="0" pn="section-2-1"> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119"/>.target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t><t><t indent="0" pn="section-2-2"> The terms "browser" and "non-browser" are defined in <xreftarget="RFC7742"/>target="RFC7742" format="default" sectionFormat="of" derivedContent="RFC7742"/> and carry the same meaning in this document. </t> </section> <sectiontitle="Relationnumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-relation-to-other-specifica">Relation to OtherSpecifications"> <t>Specifications</name> <t indent="0" pn="section-3-1"> This document is a complement to <xreftarget="RFC7657"/>,target="RFC7657" format="default" sectionFormat="of" derivedContent="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) <xreftarget="RFC3550"/>target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> streams that are multiplexed onto a single transport-layer flow. </t><t><t indent="0" pn="section-3-2"> There are a number of guidelines specified in <xreftarget="RFC7657"/>target="RFC7657" format="default" sectionFormat="of" derivedContent="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 <xreftarget="table-dscp"/>.target="tab-dscp" format="default" sectionFormat="of" derivedContent="Table 1"/>. A WebRTC application might also multiplex data channel <xreftarget="I-D.ietf-rtcweb-data-channel"/>target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/> traffic over the same 5-tuple as RTP streams, which would also be markedasper that table. The guidance in <xreftarget="RFC7657"/>target="RFC7657" format="default" sectionFormat="of" derivedContent="RFC7657"/> says that all data channel traffic would be marked with a single value that is typically differentthanfrom 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 thandefault forwardingDefault Forwarding (DF). This is expanded upon further in the next section. </t><t><t indent="0" pn="section-3-3"> This specification does not change or override the advice in any otherIETFRFCs about setting packet markings. Rather, it simply selects a subset of DSCP values that is relevant in the WebRTC context. </t><t><t indent="0" pn="section-3-4"> 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, includingdefault forwarding (DF)the DF value to provide basicbest effortbest-effort service. Even so, there is a benefitinto marking traffic even if it only benefits the first few hops. The implications are discussed inSecton 3.2 of<xreftarget="RFC7657"/>.target="RFC7657" sectionFormat="of" section="3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7657#section-3.2" derivedContent="RFC7657"/>. Further, a mitigation for such action is through an authorization mechanism. Such an authorization mechanism is outside the scope of this document. </t> </section> <sectiontitle="Inputs"> <t> WebRTC applications send and receivenumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-inputs">Inputs</name> <t indent="0" pn="section-4-1"> This document recommends DSCP values for twotypes of flowsclasses ofsignificance to this document: <list style="symbols"> <t>WebRTC flows: </t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2"> <li pn="section-4-2.1"> media flowswhichthat are RTP streams <xreftarget="I-D.ietf-rtcweb-rtp-usage"/> </t> <t>target="RFC8834" format="default" sectionFormat="of" derivedContent="RFC8834"/> </li> <li pn="section-4-2.2"> data flowswhichthat are data channels <xreftarget="I-D.ietf-rtcweb-data-channel"/> </t> </list> </t> <t>target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/> </li> </ul> <t indent="0" pn="section-4-3"> Each of the RTP streams and distinct data channelsconsistsconsist 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 sameSCTPStream Control Transmission Protocol (SCTP) association as outlined in <xreftarget="dscp-mappings"/>.) </t> <t>target="dscp-mappings" format="default" sectionFormat="of" derivedContent="Section 5"/>.) </t> <t indent="0" pn="section-4-4"> The following are the inputs provided by the WebRTC application to the browser:<list style="symbols"> <t></t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5"> <li pn="section-4-5.1"> Flow Type: The application provides this input because it knows if the flow is audio, interactive video (<xref target="RFC4594" format="default" sectionFormat="of" derivedContent="RFC4594"/> <xreftarget="RFC4594"/> <xref target="G.1010"/>target="G.1010" format="default" sectionFormat="of" derivedContent="G.1010"/>) with or without audio, or data.</t> <t></li> <li pn="section-4-5.2"> Application Priority: Another input is the relative importance of an RTP stream or data channel. Many applications have multiple flows of the sameFlow Typeflow type andoftensome 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 ishigh, medium, lowof High, Medium, Low, orvery lowVery Low importance to the application.</t> </list> </t> <t></li> </ul> <t indent="0" pn="section-4-6"> <xreftarget="I-D.ietf-rtcweb-transports"/>target="RFC8835" format="default" sectionFormat="of" derivedContent="RFC8835"/> defines in more detail what an individual flow is within the WebRTC context and priorities for media and data flows. </t><t><t indent="0" pn="section-4-7"> Currently in WebRTC, media sent over RTP is assumed to be interactive <xreftarget="I-D.ietf-rtcweb-transports"/>target="RFC8835" format="default" sectionFormat="of" derivedContent="RFC8835"/> and browser APIs do not exist to allow an application totodifferentiate between interactive and non-interactive video. </t> </section> <section anchor="dscp-mappings"title="DSCP Mappings"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-dscp-mappings">DSCP Mappings</name> <t indent="0" pn="section-5-1"> The DSCP values for each flow type of interest to WebRTC based on application priority are shown in <xreftarget="table-dscp"/>.target="tab-dscp" format="default" sectionFormat="of" derivedContent="Table 1"/>. These values are based on the framework and recommended values in <xreftarget="RFC4594"/>.target="RFC4594" format="default" sectionFormat="of" derivedContent="RFC4594"/>. A web browserSHOULD<bcp14>SHOULD</bcp14> use these values to mark the appropriate media packets. More information onEFExpedited Forwarding (EF) and Assured Forwarding (AF) can be found in <xreftarget="RFC3246"/>. More information on AF can be found intarget="RFC3246" format="default" sectionFormat="of" derivedContent="RFC3246"/> and <xreftarget="RFC2597"/>.target="RFC2597" format="default" sectionFormat="of" derivedContent="RFC2597"/>, respectively. DF isdefault forwardingDefault Forwarding, which provides the basicbest effortbest-effort service <xreftarget="RFC2474"/>. </t> <t> WebRTCtarget="RFC2474" format="default" sectionFormat="of" derivedContent="RFC2474"/>. </t> <t indent="0" pn="section-5-2"> WebRTC's use of multiple DSCP values mayencounter network blocking ofresult in packets with certain DSCPvalues.values being blocked by a network. Seesection 4.2 of<xreftarget="I-D.ietf-rtcweb-transports"/>target="RFC8835" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8835#section-4.2" derivedContent="RFC8835"/> for further discussion, including how WebRTC implementations establish and maintain connectivity when such blocking is encountered. </t><texttable anchor="table-dscp" title="Recommended<table anchor="tab-dscp" align="center" pn="table-1"> <name slugifiedName="name-recommended-dscp-values-for">Recommended DSCP Values for WebRTCApplications"> <ttcol align="center">Flow Type</ttcol> <ttcol align="center">Very Low</ttcol> <ttcol align="center">Low</ttcol> <ttcol align="center">Medium</ttcol> <ttcol align="center">High</ttcol> <c>Audio</c> <c>CS1 (8)</c> <c>DF (0)</c> <c>EF (46)</c> <c>EF (46)</c> <c> </c> <c> </c> <c> </c> <c> </c> <c> </c> <c>InteractiveApplications</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Flow Type</th> <th align="center" colspan="1" rowspan="1">Very Low</th> <th align="center" colspan="1" rowspan="1">Low</th> <th align="center" colspan="1" rowspan="1">Medium</th> <th align="center" colspan="1" rowspan="1">High</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">Audio</td> <td align="center" colspan="1" rowspan="1">LE (1)</td> <td align="center" colspan="1" rowspan="1">DF (0)</td> <td align="center" colspan="1" rowspan="1">EF (46)</td> <td align="center" colspan="1" rowspan="1">EF (46)</td> </tr> <tr> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> </tr> <tr> <td align="center" colspan="1" rowspan="1">Interactive Video with or withoutAudio</c> <c>CS1 (8)</c> <c>DF (0)</c> <c>AF42,Audio</td> <td align="center" colspan="1" rowspan="1">LE (1)</td> <td align="center" colspan="1" rowspan="1">DF (0)</td> <td align="center" colspan="1" rowspan="1">AF42, AF43 (36,38)</c> <c>AF41,38)</td> <td align="center" colspan="1" rowspan="1">AF41, AF42 (34,36)</c> <c> </c> <c> </c> <c> </c> <c> </c> <c> </c> <c>Non-Interactive36)</td> </tr> <tr> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> </tr> <tr> <td align="center" colspan="1" rowspan="1">Non-Interactive Video with or withoutAudio</c> <c>CS1 (8)</c> <c>DF (0)</c> <c>AF32,Audio</td> <td align="center" colspan="1" rowspan="1">LE (1)</td> <td align="center" colspan="1" rowspan="1">DF (0)</td> <td align="center" colspan="1" rowspan="1">AF32, AF33 (28,30)</c> <c>AF31,30)</td> <td align="center" colspan="1" rowspan="1">AF31, AF32 (26,28)</c> <c> </c> <c> </c> <c> </c> <c> </c> <c> </c> <c>Data</c> <c>CS1 (8)</c> <c>DF (0)</c> <c>AF11</c> <c>AF21</c> </texttable> <t>28)</td> </tr> <tr> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> <td align="center" colspan="1" rowspan="1"> </td> </tr> <tr> <td align="center" colspan="1" rowspan="1">Data</td> <td align="center" colspan="1" rowspan="1">LE (1)</td> <td align="center" colspan="1" rowspan="1">DF (0)</td> <td align="center" colspan="1" rowspan="1">AF11</td> <td align="center" colspan="1" rowspan="1">AF21</td> </tr> </tbody> </table> <t indent="0" pn="section-5-4"> The application priority, indicated by the columns"very low", "low","Very Low", "Low", "Medium", and"high","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. </t><t><t indent="0" pn="section-5-5"> The above table assumes that packets marked withCS1LE are treated as lower effort (i.e., "less than besteffort",effort"), such as the LE behavior described in <xreftarget="RFC3662"/>.target="RFC8622" format="default" sectionFormat="of" derivedContent="RFC8622"/>. However, the treatment ofCS1LE is implementation dependent. If an implementation treatsCS1LE as other than "less than best effort", then the actual priority (or, more precisely, theper-hop-behavior)per-hop behavior) of the packets may be changed from what is intended. It is common forCS1LE to be treated the same as DF, so applications and browsers usingCS1LE cannot assume thatCS1LE will be treated differently than DF <xreftarget="RFC7657"/>. However, it is also possible per <xref target="RFC2474"/> fortarget="RFC7657" format="default" sectionFormat="of" derivedContent="RFC7657"/>. During development of this document, the CS1traffic to be given better treatment than DF, thus caution shouldDSCP was recommended for "very low" application priority traffic; implementations that followed that recommendation <bcp14>SHOULD</bcp14> beexercised when electingupdated to useCS1. This is onethe LE DSCP instead of thecases where marking packets using these recommendations can make things worse.CS1 DSCP. </t><t><t indent="0" pn="section-5-6"> 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. </t><t><t indent="0" pn="section-5-7"> The browserSHOULD<bcp14>SHOULD</bcp14> first select the flow type of the flow. Within the flow type, the relative importance of the flowSHOULD<bcp14>SHOULD</bcp14> be used to select the appropriate DSCP value. </t><t><t indent="0" pn="section-5-8"> Currently, all WebRTC video is assumed to be interactive <xreftarget="I-D.ietf-rtcweb-transports"/>,target="RFC8835" format="default" sectionFormat="of" derivedContent="RFC8835"/>, for which theInteractive Videointeractive video DSCP values in Table 1SHOULD<bcp14>SHOULD</bcp14> be used. BrowsersMUST NOT<bcp14>MUST NOT</bcp14> use the AF3x DSCP values (forNon-Interactive Videonon-interactive video in Table 1) for WebRTC applications. Non-browser implementations of WebRTCMAY<bcp14>MAY</bcp14> 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. </t><t><t indent="0" pn="section-5-9"> 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 flowSHOULD<bcp14>SHOULD</bcp14> 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 valuesprovidesprovide additional granularity in classifying packets within a flow. For example, in a videoconferenceconference, 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). </t><t><t indent="0" pn="section-5-10"> It is worth noting that the application priority is utilized by the coupled congestion control mechanism for media flows per <xreftarget="I-D.ietf-rmcat-coupled-cc"/>target="RFC8699" format="default" sectionFormat="of" derivedContent="RFC8699"/> and the SCTP scheduler for data channel traffic per <xreftarget="I-D.ietf-rtcweb-data-channel"/>. </t> <t>target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>. </t> <t indent="0" pn="section-5-11"> For reasons discussed inSection 6 of<xreftarget="RFC7657"/>,target="RFC7657" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7657#section-6" derivedContent="RFC7657"/>, if multiple flows are multiplexed using a reliable transport (e.g.,TCP)TCP), then all of the packets for all flows multiplexed over that transport-layer flowMUST<bcp14>MUST</bcp14> be marked using the same DSCP value. Likewise, all WebRTC data channel packets transmitted over an SCTP associationMUST<bcp14>MUST</bcp14> 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, itMUST<bcp14>MUST</bcp14> reset the SCTP congestion controller after changing values.FrequentHowever, frequent changes in the DSCP value used for an SCTP association are discouraged,though,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. </t><t><t indent="0" pn="section-5-12"> For the data channel traffic multiplexed over an SCTP association, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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, theDCSPDSCP value selectedshould<bcp14>SHOULD</bcp14> be the one associated with the highest priority requested for all multiplexed flows. </t><t><t indent="0" pn="section-5-13"> If a packet enters a network that has no support for aflow type-applicationflow-type-application priority combination specified in <xreftarget="table-dscp"/>,target="tab-dscp" format="default" sectionFormat="of" derivedContent="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. </t><t><t indent="0" pn="section-5-14"> 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. </t> </section> <sectiontitle="Security Considerations"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-6-1"> 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. TheDiffServDiffserv architecture requires ingress traffic conditioning for reasons that include protecting the network from this sort of attack. </t><t><t indent="0" pn="section-6-2"> 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 toSection 7 of<xreftarget="RFC7657"/>target="RFC7657" sectionFormat="of" section="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7657#section-7" derivedContent="RFC7657"/> andSection 6 of<xreftarget="RFC4594"/>.target="RFC4594" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4594#section-6" derivedContent="RFC4594"/>. Please also see <xreftarget="I-D.ietf-rtcweb-security"/>target="RFC8826" format="default" sectionFormat="of" derivedContent="RFC8826"/> as an additional reference. </t> </section> <sectiontitle="IANA Considerations"> <t> This specification does not require any actions from IANA. </t>numbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-7-1">This document has no IANA actions.</t> </section> <sectiontitle="Downward References"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-downward-references">Downward References</name> <t indent="0" pn="section-8-1"> This specification containsadownwardsreferencereferences to <xreftarget="RFC4594"/>target="RFC4594" format="default" sectionFormat="of" derivedContent="RFC4594"/> and <xreftarget="RFC7657"/>.target="RFC7657" format="default" sectionFormat="of" derivedContent="RFC7657"/>. However, the parts of the formerRFCRFCs used by this specification are sufficiently stable forthisthese downwardreference.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. </t> </section><section title="Acknowledgements"> <t> Thanks to David Black, Magnus Westerlund, Paolo Severini, Jim Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tuexen, and Brian Carpenter</middle> <back> <references pn="section-9"> <name slugifiedName="name-references">References</name> <references pn="section-9.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words fortheir invaluable input. </t> </section> <section title="Dedication"> <t> This document is dedicateduse in RFCs tothe memory of James Polk, a long-time friend and colleague. James made important contributionsIndicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1997" month="March"/> <abstract> <t indent="0">In many standards track documents several words are used tothis specification, including serving initially as one ofsignify theprimary authors. The IETF global community mourns his loss and he willrequirements in the specification. These words are often capitalized. This document defines these words as they should bemissed dearly. </t> </section> <section title="Document History"> <t> Note to RFC Editor: Please remove this section. </t> <t>interpreted in IETF documents. This documentwas originallyspecifies anindividual submission in RTCWeb WG. The RTCWeb working group selected it to be become a WG document. Later the transport ADs requested that this be moved toInternet Best Current Practices for theTSVWG WG as that seemed to be a better match. </t> </section> </middle> <back> <references title="Normative References"> <?rfc include='reference.RFC.4594'?> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.7657'?> <?rfc include='reference.RFC.7742'?> <?rfc include='reference.I-D.ietf-rtcweb-security'?> <?rfc include='reference.I-D.ietf-rtcweb-transports'?> <?rfc include='reference.I-D.ietf-rtcweb-rtp-usage'?> <?rfc include='reference.I-D.ietf-rtcweb-data-channel'?> </references> <references title="Informative References"> <?rfc include='reference.RFC.2474'?> <?rfc include='reference.RFC.2597'?> <?rfc include='reference.RFC.3246'?> <?rfc include='reference.RFC.3550'?> <?rfc include='reference.RFC.3662'?> <?rfc include='reference.I-D.ietf-rmcat-coupled-cc'?>Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <referenceanchor="G.1010">anchor="RFC4594" target="https://www.rfc-editor.org/info/rfc4594" quoteTitle="true" derivedAnchor="RFC4594"> <front><title>End-user multimedia QoS categories</title> <author> <organization>International Telecommunications Union</organization><title>Configuration Guidelines for DiffServ Service Classes</title> <author initials="J." surname="Babiarz" fullname="J. Babiarz"> <organization showOnFrontPage="true"/> </author> <author initials="K." surname="Chan" fullname="K. Chan"> <organization showOnFrontPage="true"/> </author> <author initials="F." surname="Baker" fullname="F. Baker"> <organization showOnFrontPage="true"/> </author> <datemonth="November" year="2001"/> </front> <seriesInfo name="Recommendation" value="ITU-T G.1010"/> </reference> </references>year="2006" month="August"/> <abstract> <t indent="0">This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4594"/> <seriesInfo name="DOI" value="10.17487/RFC4594"/> </reference> <reference anchor="RFC7657" target="https://www.rfc-editor.org/info/rfc7657" quoteTitle="true" derivedAnchor="RFC7657"> <front> <title>Differentiated Services (Diffserv) and Real-Time Communication</title> <author initials="D." surname="Black" fullname="D. Black" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Jones" fullname="P. Jones"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="November"/> <abstract> <t indent="0">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.</t> </abstract> </front> <seriesInfo name="RFC" value="7657"/> <seriesInfo name="DOI" value="10.17487/RFC7657"/> </reference> <reference anchor="RFC7742" target="https://www.rfc-editor.org/info/rfc7742" quoteTitle="true" derivedAnchor="RFC7742"> <front> <title>WebRTC Video Processing and Codec Requirements</title> <author initials="A.B." surname="Roach" fullname="A.B. Roach"> <organization showOnFrontPage="true"/> </author> <date year="2016" month="March"/> <abstract> <t indent="0">This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.</t> </abstract> </front> <seriesInfo name="RFC" value="7742"/> <seriesInfo name="DOI" value="10.17487/RFC7742"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <abstract> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8622" target="https://www.rfc-editor.org/info/rfc8622" quoteTitle="true" derivedAnchor="RFC8622"> <front> <title>A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services</title> <author initials="R." surname="Bless" fullname="R. Bless"> <organization showOnFrontPage="true"/> </author> <date year="2019" month="June"/> <abstract> <t indent="0">This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.</t> <t indent="0">This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.</t> </abstract> </front> <seriesInfo name="RFC" value="8622"/> <seriesInfo name="DOI" value="10.17487/RFC8622"/> </reference> <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826" quoteTitle="true" derivedAnchor="RFC8826"> <front> <title>Security Considerations for WebRTC</title> <author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8826"/> <seriesInfo name="DOI" value="10.17487/RFC8826"/> </reference> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831" quoteTitle="true" derivedAnchor="RFC8831"> <front> <title>WebRTC Data Channels</title> <author initials="R" surname="Jesup" fullname="Randell Jesup"> <organization showOnFrontPage="true"/> </author> <author initials="S" surname="Loreto" fullname="Salvatore Loreto"> <organization showOnFrontPage="true"/> </author> <author initials="M" surname="Tüxen" fullname="Michael Tüxen"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8831"/> <seriesInfo name="DOI" value="10.17487/RFC8831"/> </reference> <reference anchor="RFC8834" target="https://www.rfc-editor.org/info/rfc8834" quoteTitle="true" derivedAnchor="RFC8834"> <front> <title>Media Transport and Use of RTP in WebRTC</title> <author initials="C." surname="Perkins" fullname="Colin Perkins"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Westerlund" fullname="Magnus Westerlund"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Ott" fullname="Jörg Ott"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8834"/> <seriesInfo name="DOI" value="10.17487/RFC8834"/> </reference> <reference anchor="RFC8835" target="https://www.rfc-editor.org/info/rfc8835" quoteTitle="true" derivedAnchor="RFC8835"> <front> <title>Transports for WebRTC</title> <author initials="H." surname="Alvestrand" fullname="Harald Alvestrand"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8835"/> <seriesInfo name="DOI" value="10.17487/RFC8835"/> </reference> </references> <references pn="section-9.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="G.1010" target="https://www.itu.int/rec/T-REC-G.1010-200111-I/en" quoteTitle="true" derivedAnchor="G.1010"> <front> <title>End-user multimedia QoS categories</title> <author> <organization showOnFrontPage="true">ITU-T</organization> </author> <date month="November" year="2001"/> </front> <seriesInfo name="ITU-T Recommendation" value="G.1010"/> </reference> <reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2474" quoteTitle="true" derivedAnchor="RFC2474"> <front> <title>Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</title> <author initials="K." surname="Nichols" fullname="K. Nichols"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Blake" fullname="S. Blake"> <organization showOnFrontPage="true"/> </author> <author initials="F." surname="Baker" fullname="F. Baker"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Black" fullname="D. Black"> <organization showOnFrontPage="true"/> </author> <date year="1998" month="December"/> <abstract> <t indent="0">This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2474"/> <seriesInfo name="DOI" value="10.17487/RFC2474"/> </reference> <reference anchor="RFC2597" target="https://www.rfc-editor.org/info/rfc2597" quoteTitle="true" derivedAnchor="RFC2597"> <front> <title>Assured Forwarding PHB Group</title> <author initials="J." surname="Heinanen" fullname="J. Heinanen"> <organization showOnFrontPage="true"/> </author> <author initials="F." surname="Baker" fullname="F. Baker"> <organization showOnFrontPage="true"/> </author> <author initials="W." surname="Weiss" fullname="W. Weiss"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Wroclawski" fullname="J. Wroclawski"> <organization showOnFrontPage="true"/> </author> <date year="1999" month="June"/> <abstract> <t indent="0">This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2597"/> <seriesInfo name="DOI" value="10.17487/RFC2597"/> </reference> <reference anchor="RFC3246" target="https://www.rfc-editor.org/info/rfc3246" quoteTitle="true" derivedAnchor="RFC3246"> <front> <title>An Expedited Forwarding PHB (Per-Hop Behavior)</title> <author initials="B." surname="Davie" fullname="B. Davie"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Charny" fullname="A. Charny"> <organization showOnFrontPage="true"/> </author> <author initials="J.C.R." surname="Bennet" fullname="J.C.R. Bennet"> <organization showOnFrontPage="true"/> </author> <author initials="K." surname="Benson" fullname="K. Benson"> <organization showOnFrontPage="true"/> </author> <author initials="J.Y." surname="Le Boudec" fullname="J.Y. Le Boudec"> <organization showOnFrontPage="true"/> </author> <author initials="W." surname="Courtney" fullname="W. Courtney"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Davari" fullname="S. Davari"> <organization showOnFrontPage="true"/> </author> <author initials="V." surname="Firoiu" fullname="V. Firoiu"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Stiliadis" fullname="D. Stiliadis"> <organization showOnFrontPage="true"/> </author> <date year="2002" month="March"/> <abstract> <t indent="0">This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3246"/> <seriesInfo name="DOI" value="10.17487/RFC3246"/> </reference> <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550"> <front> <title>RTP: A Transport Protocol for Real-Time Applications</title> <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Casner" fullname="S. Casner"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Frederick" fullname="R. Frederick"> <organization showOnFrontPage="true"/> </author> <author initials="V." surname="Jacobson" fullname="V. Jacobson"> <organization showOnFrontPage="true"/> </author> <date year="2003" month="July"/> <abstract> <t indent="0">This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="64"/> <seriesInfo name="RFC" value="3550"/> <seriesInfo name="DOI" value="10.17487/RFC3550"/> </reference> <reference anchor="RFC8699" target="https://www.rfc-editor.org/info/rfc8699" quoteTitle="true" derivedAnchor="RFC8699"> <front> <title>Coupled Congestion Control for RTP Media</title> <author initials="S." surname="Islam" fullname="S. Islam"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Welzl" fullname="M. Welzl"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Gjessing" fullname="S. Gjessing"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="January"/> <abstract> <t indent="0">When multiple congestion-controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms.</t> </abstract> </front> <seriesInfo name="RFC" value="8699"/> <seriesInfo name="DOI" value="10.17487/RFC8699"/> </reference> </references> </references> <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t indent="0" pn="section-appendix.a-1"> Thanks to <contact fullname="David Black"/>, <contact fullname="Magnus Westerlund"/>, <contact fullname="Paolo Severini"/>, <contact fullname="Jim Hasselbrook"/>, <contact fullname="Joe Marcus"/>, <contact fullname="Erik Nordmark"/>, <contact fullname="Michael Tüxen"/>, and <contact fullname="Brian Carpenter"/> for their invaluable input. </t> </section> <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-dedication">Dedication</name> <t indent="0" pn="section-appendix.b-1"> This document is dedicated to the memory of <contact fullname="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. </t> </section> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Paul E. Jones" initials="P." surname="Jones"> <organization showOnFrontPage="true">Cisco Systems</organization> <address> <email>paulej@packetizer.com</email> </address> </author> <author fullname="Subha Dhesikan" initials="S." surname="Dhesikan"> <organization showOnFrontPage="true">Individual</organization> <address> <email>sdhesikan@gmail.com</email> </address> </author> <author fullname="Cullen Jennings" initials="C." surname="Jennings"> <organization showOnFrontPage="true">Cisco Systems</organization> <address> <email>fluffy@cisco.com</email> </address> </author> <author fullname="Dan Druta" initials="D." surname="Druta"> <organization showOnFrontPage="true">AT&T</organization> <address> <email>dd5826@att.com</email> </address> </author> </section> </back> </rfc>