idnits 2.17.1 draft-jennings-rtcweb-qos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4308 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 321, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 324, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 329, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 333, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 336, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4594 (ref. '1') Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Dhesikan 3 Internet-Draft Cisco 4 Intended status: Standards Track D. Druta 5 Expires: January 10, 2013 ATT 6 C. Jennings 7 P. Jones 8 J. Polk 9 Cisco 10 July 9, 2012 12 DSCP and other packet markings for RTCWeb QoS 13 draft-jennings-rtcweb-qos-00 15 Abstract 17 Many networks, such as Service Provider and Enterprise networks, can 18 provide per packet treatments based on Differentiated Services Code 19 Points (DSCP) on a per hop basis. This document defines the 20 recommended DSCP values for browsers to use for various classes of 21 traffic. 23 This draft is a very early and far from done. It is meant to provide 24 the structure for the idea of how to do this but much discussion is 25 needed about the details. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. This document may not be modified, 31 and derivative works of it may not be created, and it may not be 32 published except as an Internet-Draft. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 10, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 1. Introduction 63 DiffServ style packet marking can help provide QoS in some 64 environments. There are many use cases where such marking does not 65 help, but it seldom make things worse, if packets are marked 66 appropriately. In other words, when attempting to avoid congestion 67 by marking certain traffic flows, say all audio or all audio and 68 video, marking too many audio and/or video flows for a given 69 network's capacity can prevent desirable results. Either too much 70 other traffic will be starved, or there is not enough capacity for 71 the preferentially marked packets (i.e., audio and/or video). 73 This draft proposes how browser and other VoIP applications can mark 74 packets. This draft does not contradict or redefine any advice from 75 previous IETF RFCs but simply provides a simple set of 76 recommendations for implementors based on the previous RFCs. 78 There are some environments where priority markings frequently help. 79 These include: 81 1. If the congested link is the broadband uplink in a Cable or DSL 82 scenario, often residential routers/NAT support preferential 83 treatment based on DSCP. 85 2. If the congested link is a local WiFi network, marking may help. 87 3. In some some cellular style deployments, markings may help in 88 cases where the network does not remove them. 90 Traditionally DSCP values have been thought of as being site 91 specific, with each site selecting its own code points for each QoS 92 level. However in the RTCWeb use cases, the browsers need to set 93 them to something when there is no site specific information. This 94 document describes a reasonable default set of DSCP code point values 95 drawn from existing RFCs and common usage. These code points are 96 solely defaults. Future drafts may define mechanisms for site 97 specific mappings to override the values provided in this draft. 99 This draft defines some inputs that the browser can look at to 100 determine how to set the various packet markings and defines the a 101 mapping from abstract QoS policies (media type, priority level) to 102 those packet markings. 104 2. Terminology 106 TODO - add the boiler plate 108 3. Inputs 110 The first input is the type of the media. The browser provides this 111 input as it knows if the media is audio, video, or data. In this 112 specification, both interactive and streaming media is included. 113 They are treated in different categories as their QoS requirements 114 are slightly different. The second input is the relative treatment 115 of the stream within that session. Many applications have multiple 116 video streams and often some are more important than others. 117 Javascript applications can tell the browser whether a particular 118 media stream is high, medium, or low importance to the application. 120 4. DSCP Mappings 122 +-----------------------+-----------+-----------+-----------+ 123 | | Low | Medium | High | 124 +-----------------------+-----------+-----------+-----------+ 125 | Audio | 46 (EF) | 46 (EF) | 46 (EF) | 126 | Interactive Video | 38 (AF43) | 36 (AF42) | 34 (AF41) | 127 | Non-Interactive Video | 26 (AF33) | 28 (AF32) | 30 (AF31) | 128 | Data | 8 (CS1) | 0 (BE) | 10 (AF11) | 129 +-----------------------+-----------+-----------+-----------+ 131 Table 1 133 5. QCI Mapping 135 +-----------------------+-----+--------+------+ 136 | | Low | Medium | High | 137 +-----------------------+-----+--------+------+ 138 | Audio | 1 | 1 | 1 | 139 | Interactive Video | 2 | 2 | 2 | 140 | Non-Interactive Video | 8 | 6 | 4 | 141 | Data | 9 | 9 | 3 | 142 +-----------------------+-----+--------+------+ 144 Table 2 146 This corresponds to the mapping provided in TODO REF which are: QCI 147 values (LTE) 149 +-------+--------+-----+--------------------------------------------+ 150 | Value | | | Use | 151 +-------+--------+-----+--------------------------------------------+ 152 | 1 | GBR | 2 | Interactive Voice | 153 | 2 | GBR | 4 | Interactive Video | 154 | 3 | GBR | 5 | Non-Interactive Video | 155 | 4 | GBR | 3 | Real Time Gaming | 156 | 5 | Non-BG | R 1 | IMS Signalling | 157 | 6 | Non-BG | R 7 | interactive Voice, video, games | 158 | 7-9 | Non-BG | R 6 | non interactive video / TCP web, email, / | 159 | | | | Platinum vs gold user | 160 +-------+--------+-----+--------------------------------------------+ 162 Table 3 164 6. WiFI Mapping 166 +-----------------------+-----+--------+------+ 167 | | Low | Medium | High | 168 +-----------------------+-----+--------+------+ 169 | Audio | 6 | 6 | 6 | 170 | Interactive Video | 5 | 5 | 5 | 171 | Non-Interactive Video | 4 | 4 | 4 | 172 | Data | 1 | 0 | 3 | 173 +-----------------------+-----+--------+------+ 175 Table 4 177 This corresponds to the mappings from TODO REF of 178 +-------+----+------------------+---------------------+-------------+ 179 | Value | | Traffic Type | Access Category | Designation | 180 | | | | (AC) | | 181 +-------+----+------------------+---------------------+-------------+ 182 | 1 | BK | Background | AC_BK | Background | 183 | 2 | - | (spare) | AC_BK | Background | 184 | 0 | BE | Best Effort | AC_BE | Best Effort | 185 | 3 | EE | Excellent Effort | AC_BE | Best Effort | 186 | 4 | CL | Controlled Loat | AC_VI | Video | 187 | 5 | VI | Video | AC_VI | Video | 188 | 6 | VO | Voice | AC_VO | Voice | 189 | 7 | NC | Network Control | AC_VO | Voice | 190 +-------+----+------------------+---------------------+-------------+ 192 Table 5 194 7. W3C API Implications 196 To work with this proposal, the W3C specification would need to 197 provide a way to specify the importance of media and data streams. 199 The W3C API should also provide a way for the application to find out 200 the source and destination IP and ports of any flow as well as the 201 DSCP value or other markings in use for that flow. The JS 202 application can then communicate this to a web service that may 203 install a particular policy for that flow. 205 8. Security Considerations 207 TODO - discuss implications of what browser can set and what JS can 208 set 210 9. IANA Considerations 212 This specification does not require any actions from IANA. 214 10. Acknowledgements 216 Thanks for hints on code to do this from Paolo Severini, Jim 217 Hasselbrook, Joe Marcus, and Erik Nordmark. 219 11. Appendix: Code Hints 221 On windows setting the source interface works but BSD, OSX, Linux use 222 weak end-system model and will route out different interface if that 223 looks like a better route. (TODO - Can someone verify this with 224 specific versions?) 226 In windows you might be able to tell something about priority of an 227 interface for ICE purposes with WlanQueryInterface or GetIfTable. 229 The specific mechanisms required to set DSCP code points depend on 230 the application platform. 232 In windows, setting the DSCP is not easy. See Knowledge Base Article 233 KB248611. TODO - add more information about what can be done for 234 windows. 236 For most unix variants, the following program can set DSCP. 238 TODO - make this work in V6. For v6 have a look at IPv6_TCLASS or 239 better the tclass part of sin6_flowid for IPv6 241 TODO - Can someone test and report back results of program in iOS, 242 Android, Linux, OSX, BSD. 244 Example test program: 246 #include 247 #include 248 #include 249 #include 250 #include 251 #include 252 #include 253 #include 254 #include 255 #include 257 #define MSG "Hello, World!" 259 int 260 main(void) { 261 int sock = -1; 262 struct sockaddr *local_addr = NULL; 263 struct sockaddr_in sockin, host; 264 int tos = 0x60; /* CS3 */ 265 socklen_t socksiz = 0; 266 char *buffer = NULL; 268 sock = socket(AF_INET, SOCK_DGRAM, 0); 269 if (sock < 0) { 270 fprintf(stderr,"Error: %s\n", strerror(errno)); 271 exit(-1); 272 } 274 memset(&sockin, 0, sizeof(sockin)); 275 sockin.sin_family = PF_INET; 276 sockin.sin_addr.s_addr = inet_addr("11.1.1.1"); 277 socksiz = sizeof(sockin); 279 local_addr = (struct sockaddr *) &sockin; 281 /* Set ToS/DSCP */ 282 if (setsockopt(sock, IPPROTO_IP, IP_TOS, &tos, 283 sizeof(tos)) < 0) { 284 fprintf(stderr,"Error setting TOS: %s\n", strerror(errno)); 285 } 287 /* Bind to a specific local address */ 288 if (bind(sock, local_addr, socksiz) < 0) { 289 fprintf(stderr,"Error binding to socket: %s\n", strerror(errno)); 290 close(sock); sock=-1; 291 exit(-1); 292 } 294 buffer = (char *) malloc(strlen(MSG) + 1); 295 if ( buffer == NULL ) { 296 fprintf(stderr,"Error allocating memory: %s\n", strerror(errno)); 297 close( sock ); sock=-1; 298 exit(-1); 299 } 300 strlcpy(buffer, MSG, strlen(MSG) + 1); 301 memset(&host, 0, sizeof(host)); 302 host.sin_family = PF_INET; 303 host.sin_addr.s_addr = inet_addr("10.1.1.1"); 304 host.sin_port = htons(12345); 306 if (sendto(sock, buffer, strlen(buffer), 0, 307 (struct sockaddr *) &host, sizeof(host)) < 0) { 308 fprintf(stderr,"Error sending message: %s\n", strerror(errno)); 309 close(sock); sock=-1; 310 free(buffer); buffer=NULL; 311 exit(-1); 312 } 313 free(buffer); buffer=NULL; 314 close(sock); sock=-1; 316 return 0; 317 } 319 12. Normative References 321 [1] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines 322 for DiffServ Service Classes", RFC 4594, August 2006. 324 [2] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 325 Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An 326 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, 327 March 2002. 329 [3] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 330 the Differentiated Services Field (DS Field) in the IPv4 and 331 IPv6 Headers", RFC 2474, December 1998. 333 [4] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured 334 Forwarding PHB Group", RFC 2597, June 1999. 336 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 337 Levels", BCP 14, RFC 2119, March 1997. 339 Authors' Addresses 341 Subha Dhesikan 342 Cisco 344 Email: sdhesika@cisco.com 346 Dan Druta 347 ATT 349 Email: dd5826@att.com 351 Cullen Jennings 352 Cisco 354 Email: fluffy@cisco.com 355 Paul Jones 356 Cisco 358 Email: paulej@packetizer.com 360 James Polk 361 Cisco 363 Email: jmpolk@cisco.com