One document matched: draft-jennings-rtcweb-qos-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="std" docName="draft-jennings-rtcweb-qos-00"
ipr="noDerivativesTrust200902">
<front>
<title abbrev="RTCWeb QoS">DSCP and other packet markings for
RTCWeb QoS</title>
<author fullname="Subha Dhesikan" initials="S."
surname="Dhesikan">
<organization>Cisco</organization>
<address>
<email>sdhesika@cisco.com</email>
</address>
</author>
<author fullname="Dan Druta" initials="D." surname="Druta">
<organization>ATT</organization>
<address>
<email>dd5826@att.com</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C."
surname="Jennings">
<organization>Cisco</organization>
<address>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Paul Jones" initials="P." surname="Jones">
<organization>Cisco</organization>
<address>
<email>paulej@packetizer.com</email>
</address>
</author>
<author fullname="James Polk" initials="J." surname="Polk">
<organization>Cisco</organization>
<address>
<email>jmpolk@cisco.com</email>
</address>
</author>
<date day="9" month="July" year="2012" />
<abstract>
<t>Many networks, such as Service Provider and Enterprise
networks, can provide per packet treatments based on
Differentiated Services Code Points (DSCP) on a per hop basis. This document
defines the recommended DSCP values for browsers to use for
various classes of traffic.</t>
<t>This draft is a very early and far from done. It is meant
to provide the structure for the idea of how to do this but
much discussion is needed about the details.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DiffServ style packet marking can help provide QoS in some
environments. There are many use cases where such marking does not help,
but it seldom make things worse, if packets are marked appropriately. In
other words, when attempting to avoid congestion by marking certain
traffic flows, say all audio or all audio and video, marking too many
audio and/or video flows for a given network's capacity can prevent
desirable results. Either too much other traffic will be starved, or there
is not enough capacity for the preferentially marked packets (i.e., audio
and/or video).
</t>
<t>
This draft proposes how
browser and other VoIP applications can mark packets. This
draft does not contradict or redefine any advice from
previous IETF RFCs but simply provides a simple set of
recommendations for implementors based on the previous
RFCs.</t>
<t>There are some environments where priority markings
frequently help. These include:</t>
<t>1. If the congested link is the broadband uplink in a
Cable or DSL scenario, often residential routers/NAT support
preferential treatment based on DSCP.</t>
<t>2. If the congested link is a local WiFi network, marking
may help.</t>
<t>3. In some some cellular style deployments, markings may
help in cases where the network does not remove them.</t>
<t>Traditionally DSCP values have been thought of as being
site specific, with each site selecting its own code points
for each QoS level. However in the RTCWeb use cases, the
browsers need to set them to something when there is no site
specific information. This document describes a reasonable
default set of DSCP code point values drawn from existing
RFCs and common usage. These code points are solely defaults.
Future drafts may define mechanisms for site specific
mappings to override the values provided in this draft.</t>
<t>This draft defines some inputs that the browser can look
at to determine how to set the various packet markings and
defines the a mapping from abstract QoS policies (media type,
priority level) to those packet markings.</t>
</section>
<section title="Terminology">
<t>TODO - add the boiler plate</t>
</section>
<section title="Inputs">
<t>The first input is the type of the media. The browser
provides this input as it knows if the media is audio, video,
or data. In this specification, both interactive and
streaming media is included. They are treated in different
categories as their QoS requirements are slightly different.
The second input is the relative treatment of the stream
within that session. Many applications have multiple video
streams and often some are more important than others.
Javascript applications can tell the browser whether a
particular media stream is high, medium, or low importance to
the application.</t>
</section>
<section title="DSCP Mappings">
<texttable anchor="table-dscp">
<ttcol align='left'></ttcol>
<ttcol align='center'>Low</ttcol>
<ttcol align='center'>Medium</ttcol>
<ttcol align='center'>High</ttcol>
<c>Audio</c>
<c>46 (EF)</c>
<c>46 (EF)</c>
<c>46 (EF)</c>
<c>Interactive Video</c>
<c>38 (AF43)</c>
<c>36 (AF42)</c>
<c>34 (AF41)</c>
<c>Non-Interactive Video</c>
<c>26 (AF33)</c>
<c>28 (AF32)</c>
<c>30 (AF31)</c>
<c>Data</c>
<c>8 (CS1)</c>
<c>0 (BE)</c>
<c>10 (AF11)</c>
</texttable>
<t></t>
</section>
<section title="QCI Mapping">
<texttable anchor="table-qci">
<ttcol align='left'></ttcol>
<ttcol align='center'>Low</ttcol>
<ttcol align='center'>Medium</ttcol>
<ttcol align='center'>High</ttcol>
<c>Audio</c>
<c>1</c>
<c>1</c>
<c>1</c>
<c>Interactive Video</c>
<c>2</c>
<c>2</c>
<c>2</c>
<c>Non-Interactive Video</c>
<c>8</c>
<c>6</c>
<c>4</c>
<c>Data</c>
<c>9</c>
<c>9</c>
<c>3</c>
</texttable>
<t>This corresponds to the mapping provided in TODO REF which
are: QCI values (LTE)</t>
<texttable anchor="table-qci-ref">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'></ttcol>
<ttcol align='center'></ttcol>
<ttcol align='center'>Use</ttcol>
<c>1</c>
<c>GBR</c>
<c>2</c>
<c>Interactive Voice</c>
<c>2</c>
<c>GBR</c>
<c>4</c>
<c>Interactive Video</c>
<c>3</c>
<c>GBR</c>
<c>5</c>
<c>Non-Interactive Video</c>
<c>4</c>
<c>GBR</c>
<c>3</c>
<c>Real Time Gaming</c>
<c>5</c>
<c>Non-BG</c>
<c>R 1</c>
<c>IMS Signalling</c>
<c>6</c>
<c>Non-BG</c>
<c>R 7</c>
<c>interactive Voice, video, games</c>
<c>7-9</c>
<c>Non-BG</c>
<c>R 6</c>
<c>non interactive video / TCP web, email, / Platinum vs
gold user</c>
</texttable>
</section>
<section title="WiFI Mapping">
<texttable anchor="table-wifi">
<ttcol align='left'></ttcol>
<ttcol align='center'>Low</ttcol>
<ttcol align='center'>Medium</ttcol>
<ttcol align='center'>High</ttcol>
<c>Audio</c>
<c>6</c>
<c>6</c>
<c>6</c>
<c>Interactive Video</c>
<c>5</c>
<c>5</c>
<c>5</c>
<c>Non-Interactive Video</c>
<c>4</c>
<c>4</c>
<c>4</c>
<c>Data</c>
<c>1</c>
<c>0</c>
<c>3</c>
</texttable>
<t>This corresponds to the mappings from TODO REF of</t>
<texttable anchor="table-wifi-ref">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'></ttcol>
<ttcol align='center'>Traffic Type</ttcol>
<ttcol align='center'>Access Category (AC)</ttcol>
<ttcol align='center'>Designation</ttcol>
<c>1</c>
<c>BK</c>
<c>Background</c>
<c>AC_BK</c>
<c>Background</c>
<c>2</c>
<c>-</c>
<c>(spare)</c>
<c>AC_BK</c>
<c>Background</c>
<c>0</c>
<c>BE</c>
<c>Best Effort</c>
<c>AC_BE</c>
<c>Best Effort</c>
<c>3</c>
<c>EE</c>
<c>Excellent Effort</c>
<c>AC_BE</c>
<c>Best Effort</c>
<c>4</c>
<c>CL</c>
<c>Controlled Loat</c>
<c>AC_VI</c>
<c>Video</c>
<c>5</c>
<c>VI</c>
<c>Video</c>
<c>AC_VI</c>
<c>Video</c>
<c>6</c>
<c>VO</c>
<c>Voice</c>
<c>AC_VO</c>
<c>Voice</c>
<c>7</c>
<c>NC</c>
<c>Network Control</c>
<c>AC_VO</c>
<c>Voice</c>
</texttable>
</section>
<section title="W3C API Implications">
<t>To work with this proposal, the W3C specification would
need to provide a way to specify the importance of media and
data streams.</t>
<t>The W3C API should also provide a way for the application
to find out the source and destination IP and ports of any
flow as well as the DSCP value or other markings in use for
that flow. The JS application can then communicate this to a
web service that may install a particular policy for that
flow.</t>
</section>
<section title="Security Considerations">
<t>TODO - discuss implications of what browser can set and
what JS can set</t>
</section>
<section title="IANA Considerations">
<t>This specification does not require any actions from
IANA.</t>
</section>
<section title="Acknowledgements">
<t>Thanks for hints on code to do this from Paolo Severini,
Jim Hasselbrook, Joe Marcus, and Erik Nordmark.</t>
</section>
<section title="Appendix: Code Hints ">
<t>On windows setting the source interface works but BSD,
OSX, Linux use weak end-system model and will route out
different interface if that looks like a better route. (TODO
- Can someone verify this with specific versions?)</t>
<t>In windows you might be able to tell something about
priority of an interface for ICE purposes with
WlanQueryInterface or GetIfTable.</t>
<t>The specific mechanisms required to set DSCP code points
depend on the application platform.</t>
<t>In windows, setting the DSCP is not easy. See Knowledge
Base Article KB248611. TODO - add more information about what
can be done for windows.</t>
<t>For most unix variants, the following program can set
DSCP.</t>
<t>TODO - make this work in V6. For v6 have a look at
IPv6_TCLASS or better the tclass part of sin6_flowid for
IPv6</t>
<t>TODO - Can someone test and report back results of program
in iOS, Android, Linux, OSX, BSD.</t>
<t>Example test program:</t>
<figure>
<artwork><![CDATA[
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#define MSG "Hello, World!"
int
main(void) {
int sock = -1;
struct sockaddr *local_addr = NULL;
struct sockaddr_in sockin, host;
int tos = 0x60; /* CS3 */
socklen_t socksiz = 0;
char *buffer = NULL;
sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock < 0) {
fprintf(stderr,"Error: %s\n", strerror(errno));
exit(-1);
}
memset(&sockin, 0, sizeof(sockin));
sockin.sin_family = PF_INET;
sockin.sin_addr.s_addr = inet_addr("11.1.1.1");
socksiz = sizeof(sockin);
local_addr = (struct sockaddr *) &sockin;
/* Set ToS/DSCP */
if (setsockopt(sock, IPPROTO_IP, IP_TOS, &tos,
sizeof(tos)) < 0) {
fprintf(stderr,"Error setting TOS: %s\n", strerror(errno));
}
/* Bind to a specific local address */
if (bind(sock, local_addr, socksiz) < 0) {
fprintf(stderr,"Error binding to socket: %s\n", strerror(errno));
close(sock); sock=-1;
exit(-1);
}
buffer = (char *) malloc(strlen(MSG) + 1);
if ( buffer == NULL ) {
fprintf(stderr,"Error allocating memory: %s\n", strerror(errno));
close( sock ); sock=-1;
exit(-1);
}
strlcpy(buffer, MSG, strlen(MSG) + 1);
memset(&host, 0, sizeof(host));
host.sin_family = PF_INET;
host.sin_addr.s_addr = inet_addr("10.1.1.1");
host.sin_port = htons(12345);
if (sendto(sock, buffer, strlen(buffer), 0,
(struct sockaddr *) &host, sizeof(host)) < 0) {
fprintf(stderr,"Error sending message: %s\n", strerror(errno));
close(sock); sock=-1;
free(buffer); buffer=NULL;
exit(-1);
}
free(buffer); buffer=NULL;
close(sock); sock=-1;
return 0;
}
]]></artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC4594'>
<front>
<title>Configuration Guidelines for DiffServ Service
Classes</title>
<author initials='J.' surname='Babiarz'
fullname='J. Babiarz'>
<organization />
</author>
<author initials='K.' surname='Chan' fullname='K. Chan'>
<organization />
</author>
<author initials='F.' surname='Baker'
fullname='F. Baker'>
<organization />
</author>
<date year='2006' month='August' />
</front>
<seriesInfo name='RFC' value='4594' />
<format type='TXT' octets='144044'
target='http://www.rfc-editor.org/rfc/rfc4594.txt' />
</reference>
<reference anchor='RFC3246'>
<front>
<title>An Expedited Forwarding PHB (Per-Hop
Behavior)</title>
<author initials='B.' surname='Davie'
fullname='B. Davie'>
<organization />
</author>
<author initials='A.' surname='Charny'
fullname='A. Charny'>
<organization />
</author>
<author initials='J.C.R.' surname='Bennet'
fullname='J.C.R. Bennet'>
<organization />
</author>
<author initials='K.' surname='Benson'
fullname='K. Benson'>
<organization />
</author>
<author initials='J.Y.' surname='Le Boudec'
fullname='J.Y. Le Boudec'>
<organization />
</author>
<author initials='W.' surname='Courtney'
fullname='W. Courtney'>
<organization />
</author>
<author initials='S.' surname='Davari'
fullname='S. Davari'>
<organization />
</author>
<author initials='V.' surname='Firoiu'
fullname='V. Firoiu'>
<organization />
</author>
<author initials='D.' surname='Stiliadis'
fullname='D. Stiliadis'>
<organization />
</author>
<date year='2002' month='March' />
</front>
<seriesInfo name='RFC' value='3246' />
<format type='TXT' octets='33896'
target='http://www.rfc-editor.org/rfc/rfc3246.txt' />
</reference>
<reference anchor='RFC2474'>
<front>
<title abbrev='Differentiated Services Field'>Definition
of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers</title>
<author initials='K.' surname='Nichols'
fullname='Kathleen Nichols'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country>
</postal>
<phone>+1 408 525 4857</phone>
<email>kmn@cisco.com</email>
</address>
</author>
<author initials='S.' surname='Blake'
fullname='Steven Blake'>
<organization>Torrent Networking
Technologies</organization>
<address>
<postal>
<street>3000 Aerial Center</street>
<city>Morrisville</city>
<region>NC</region>
<code>27560</code>
<country>USA</country>
</postal>
<phone>+1 919 468 8466 x232</phone>
<email>slblake@torrentnet.com</email>
</address>
</author>
<author initials='F.' surname='Baker'
fullname='Fred Baker'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>USA</country>
</postal>
<phone>+1 408 526 4257</phone>
<email>fred@cisco.com</email>
</address>
</author>
<author initials='D.L.' surname='Black'
fullname='David L. Black'>
<organization>EMC Corporation</organization>
<address>
<postal>
<street>35 Parkwood Drive</street>
<city>Hopkinton</city>
<region>MA</region>
<code>01748</code>
<country>USA</country>
</postal>
<phone>+1 508 435 1000 x76140</phone>
<email>black_david@emc.com</email>
</address>
</author>
<date year='1998' month='December' />
<area>Internet</area>
<keyword>internet protocol version 4</keyword>
<keyword>IPv6</keyword>
<keyword>IPv4</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>type of service</keyword>
</front>
<seriesInfo name='RFC' value='2474' />
<format type='TXT' octets='50576'
target='http://www.rfc-editor.org/rfc/rfc2474.txt' />
<format type='HTML' octets='67719'
target='http://xml.resource.org/public/rfc/html/rfc2474.html' />
<format type='XML' octets='62259'
target='http://xml.resource.org/public/rfc/xml/rfc2474.xml' />
</reference>
<reference anchor='RFC2597'>
<front>
<title>Assured Forwarding PHB Group</title>
<author initials='J.' surname='Heinanen'
fullname='Juha Heinanen'>
<organization>Telia Finland</organization>
<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>
<email>jh@telia.fi</email>
</address>
</author>
<author initials='F.' surname='Baker'
fullname='Fred Baker'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author initials='W.' surname='Weiss'
fullname='Walter Weiss'>
<organization>Lucent Technologies</organization>
<address>
<postal>
<street>300 Baker Avenue</street>
<street>Suite 100</street>
<city>Concord</city>
<region>MA</region>
<code>01742-2168</code>
<country>US</country>
</postal>
<email>wweiss@lucent.com</email>
</address>
</author>
<author initials='J.' surname='Wroclawski'
fullname='J. Wroclawski'>
<organization>MIT Laboratory for Computer
Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>
<email>jtw@lcs.mit.edu</email>
</address>
</author>
<date year='1999' month='June' />
</front>
<seriesInfo name='RFC' value='2597' />
<format type='TXT' octets='24068'
target='http://www.rfc-editor.org/rfc/rfc2597.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs
to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner'
fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723'
target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491'
target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777'
target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:01:23 |