idnits 2.17.1 draft-polk-tsvwg-diffserv-stds-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 4302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk 3 Internet-Draft Cisco 4 Intended status: Informational July 9, 2012 5 Expires: January 9, 2012 7 The Problem Statement for the Standard 8 Configuration of DiffServ Service Classes 9 draft-polk-tsvwg-diffserv-stds-problem-statement-00.txt 11 Abstract 13 This document describes the problem statement on two recently 14 proposed expansions to DiffServ. The first of these expansions 15 proposes updating the informational RFC 4594 document to standards 16 track status, while making the necessary changes to make it current; 17 for example, creating more granular traffic treatments, some with 18 new Per Hop Behaviors (PHB). The second proposal defines 6 new 19 DiffServ Codepoints necessary from these new PHBs in the proposal 20 within the first draft. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 9, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Brief Overview of RFC 4594 and RFC 5127 . . . . . . . . . . . 3 58 2.1 Brief Overview of RFC 4594 . . . . . . . . . . . . . . . . 3 59 2.2 Brief Overview of RFC 5127 . . . . . . . . . . . . . . . . 4 60 3. Brief Discussion of the RFC 4594 Update Draft . . . . . . . . 5 61 4. Conclusion and What's Next . . . . . . . . . . . . . . . . . 7 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1 Normative References . . . . . . . . . . . . . . . . . . 8 67 8.2 Informative References . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Differentiated Services (DiffServ) [RFC2474] creates an IP header 73 marking or indicator with which intermediate nodes (i.e., routers 74 and switches) can make policy decisions. These 6-bit values are 75 called Differentiated Services Codepoint Point (DSCP) values. DSCP 76 values are used to differentiate packet treatment within an 77 intermediate node, not across a network, as the conditions affecting 78 that marking are different within each node. This is called Per Hop 79 Behavior (PHB). In other words, even though a packet has the same 80 DSCP from source to destination, it can and often does experience 81 different treatment depending on the conditions of the nodes it 82 traverses on its journey. 84 The DiffServ architecture allows for DSCP values within a packet to 85 be changed, or remarked, any number of times. In other words, a 86 packet can have its DSCP remarked at every layer-3 hop throughout 87 the life of that packet. This practice actually occurs infrequently, 88 but it is allowed. 90 At issue is a combination of the number of networks or endpoints 91 that are choosing to use DiffServ markings, and the number of 92 administrative domains (called "networks" in this document) a packet 93 traverses with different policies for how packet flows of a similar 94 type (e.g., a voice flow, or an email flow, etc.) are to be marked. 96 The community presently has RFC 4594 [RFC4594], which is an 97 informational guideline on how networks can or should mark certain 98 packet flows with differing traffic characteristics using DiffServ. 99 There are several reasons why this informational RFC lacks the 100 necessary clarity and strength to reach widespread adoption: 102 o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of 103 which is for aggregating many 6-bit DSCP values into a 3-bit (8 104 value) field used specifically by service provider (SP) networks. 106 o some believe both RFCs are for SPs, while others ignore RFC 5127 107 and use RFC 4594 as if it were standards track or BCP. 109 o some believe RFC 5127 is for SPs only, and want RFC 4594 to 110 reduce the number of DSCPs within its guidelines to recommend 111 using only 3 or 4 DSCPs. This seems to stem from a manageability 112 and operational perspective. 114 o some know RFC 4594 is informational and do not follow its 115 guidelines specifically because it is informational. 117 o some use DSCP values that are not defined within RFC 4594, making 118 mapping between different networks using similar or identical 119 application flows difficult. 121 o some believe enterprise networks should not use either RFC except 122 at the edge of their networks, where they directly connect to SP 123 networks. 125 o some argue that the services classes guidance per class is too 126 broad and are therefore not sure in which service class a 127 particular application is to reside. 129 This document is not intended to reach RFC status. Rather, it is to 130 stimulate discussion on both RFC 4594 and 5127 to lessen existing 131 confusion within the community. It should be noted that RFC 4594 has 132 an offered update within TSVWG [ID-4594-UPDATE]. This draft has 133 created some heated discussions within that WG before and during the 134 Paris IETF meeting. 136 First, we'll discuss briefly RFCs 4594 and 5127 in Section 2. Then 137 we will discussion what the update to RFC 4594 proposes differently 138 and what we expect to happen to RFC 5127 in Section 3. 140 2. Brief Overview of RFC 4594 and RFC 5127 142 2.1 Brief Overview of RFC 4594 144 Essentially, RFC 4594 is a guideline for how to choose which DSCP to 145 use based on the traffic characteristics an application flow needs 146 to experience within a network for optimal performance. RFC 4594 147 specifically points to several existing standards-track DiffServ 148 RFCs to augment the text in each of those RFCs, without violating 149 any of the rules within each of those documents. RFC 4594: 151 o painstakingly lays out definitions and guidelines for each service 152 class. 154 o clearly indicates each service class's tolerance to delay, jitter 155 and packet loss. 157 o details the conditioning treatments at the Differentiated Services 158 (DS) edge. 160 o categorizes traffic characteristics into 12 service classes 161 utilizing one or more DSCPs: 163 Network Control Broadcast Video 164 Telephony Low-Latency Data 165 Signaling OAM 166 Multimedia Conferencing High-throughput Data 167 Realtime Interactive Standard 168 Multimedia Streaming Low-priority Data 170 2.2 Brief Overview of RFC 5127 172 At its barest, RFC 5127 recommends that, of the many service classes 173 described within RFC 4594, each having different traffic 174 characteristics, similar service classes be grouped or aggregated 175 into 3, 4, or 5 markings for SP traversal. This limitation of the 176 number of individual service classes is partly to reduce the number 177 of separate distinctions traversing over their network because SPs 178 have difficulty managing what is deemed 'too many' different 179 classes. Another part for this reduction is customer expectations of 180 meeting contractual Service Level Agreements (SLAs). 182 To this end, and perhaps because of it, MPLS was designed with only 183 8 values of priority differentiation, i.e., the 3 EXP bits. To be 184 fair, LAN based IEEE has only a 3-bit priority field as well within 185 its specifications, known as the Priority Code Point (PCP), as part 186 of the 802.1Q header spec. IEEE 802.1e, which defines QoS over 187 Wi-Fi, also only defines 8 levels (called User Priority or UP 188 codes). 190 The result is to have the IETF within RFC 5127 recommend the 191 following (which is Figure 2 within that RFC): 193 ------------------------------------------------------------ 194 |Treatment |Treatment || DSCP | 195 |Aggregate |Aggregate || | 196 | |Behavior || | 197 |==========+==========++=====================================| 198 | Network | CS || CS6 | 199 | Control |(RFC 2474)|| | 200 |==========+==========++=====================================| 201 | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | 202 | Time |(RFC 3246)|| | 203 |==========+==========++=====================================| 204 | Assured | AF || CS2, AF31, AF21, AF11 | 205 | Elastic |(RFC 2597)||-------------------------------------| 206 | | || AF32, AF22, AF12 | 207 | | ||-------------------------------------| 208 | | || AF33, AF23, AF13 | 209 |==========+==========++=====================================| 210 | Elastic | Default || Default, (CS0) | 211 | |(RFC 2474)||-------------------------------------| 212 | | || CS1 | 213 ------------------------------------------------------------ 215 Figure 1: Treatment Aggregate Behavior 217 RFC 5127 goes on to recommend the marking and treatments on either 218 side of the provider edge remain the same. In other words, the DSCP 219 values remain the same and are used to determine which queue to 220 place the packets into within the aggregates, where the packets are 221 treated the same within that tunnel until the egress provider edge. 223 Many within enterprise networks do not pay attention to what RFC 224 5127 says because they are sufficiently removed from dealing with 225 the constraints of very few DSCP values or the need to aggregate 226 DSCP values into groups. 228 3. Brief Discussion of the RFC 4594 Update Draft 230 The RFC 4594 update draft [ID-4594-UPDATE] proposes to update what 231 has occurred since RFC 4594 was written (i.e., 2006), in which more 232 granular service classes can be differentiated by application 233 requirements. For example, Figure 2 within RFC 4594 identifies 234 "Telephony" as having 'Fixed-size small packets'. That is not true 235 for today's video flow, therefore it needs to be modified. The 236 update draft currently breaks out audio and video separately to 237 reflect this different, as well as the ability to treat each traffic 238 type differently within a network. Another example is gaming and 239 TCP. The two were believed by most, and it is still believed by many 240 that gaming requires a UDP delivery due to the requirements for 241 timely delivery of packets and that retransmissions would cause 242 delays and bad things to happen to gaming applications. This was 243 proved false within [ID-TCMTF], in which the author of that document 244 had a presentation showing TCP was used and viable. 246 [RFC5865] created a new Expedited Forwarding (EF) DSCP value called 247 VOICE-ADMIT, the second time an application is identified within the 248 DiffServ realm. The first was the service class Broadcast Video, 249 which is poorly used within RFC 4594 because other types of flows 250 can be 'broadcast' other than video, such as audio. From this, 251 [ID-4594-UPDATE] moved in two directions: 253 o it called out two service classes (audio and video), even though 254 audio and video packets are not the only types of packets within 255 each traffic characteristic. 257 o it removed "Video" from the Broadcast service class name. 259 From the resistance to this proposal within [ID-4594-UPDATE], 260 perhaps other service class label names should be used. 262 The draft also recognizes the differences in video traffic, even 263 though it is always carried over RTP [RFC3550]. Aside from silence 264 suppression, video traffic varies far more than audio traffic. For 265 example, video is 267 o far more variable in bandwidth utilization within the same flow. 269 o far more variable in packet size. 271 o at different business priorities in some networks based on a 272 configuration. For example, desktop video often is of less 273 important than Telepresence video on the same network. Lacking 274 congestion, the two are treated the same. When congestion exists, 275 one is given priority over the other. 277 Consequently any service class that contains video needs to account 278 for larger packet size variation than audio, which was equally true 279 in 2006, but not contained in RFC 4594. 281 Further, with the publication of RFC 5865, the concept of 'capacity 282 admitted' traffic flows have been defined within DiffServ, and are 283 being expanded with the proposal within this new draft 284 [ID-NEW-DSCPS]. There are differing opinions as to whether the 285 realtime Treatment Aggregate in Figure 1 above should also contain 286 these capacity admitted flows, or if 'capacity admitted' traffic 287 flows should have their own Treatment Aggregate containing all 288 realtime capacity admitted traffic. Mixing capacity admitted traffic 289 with unbounded realtime traffic seems to be trouble from a 290 predictability point of view within routers believing they 291 individually understand exactly how much traffic will be traversing 292 each interface and at what rate. 294 All this said, there is a valid argument to constrain or prevent any 295 DSCP value from being assigned to a single application, mostly due 296 to the limitation of the overall number of DSCP values available for 297 use. [ID-4594-UPDATE] provides at least several applications per 298 service class (or DSCP); a fact many have overlooked to date. 300 [ID-4594-UPDATE] is not only about or because of realtime traffic. 301 It is also an overall update to the ideas and guidelines within RFC 302 4594, with the intent to make that document a standards track 303 document for interoperability purposes. 305 4. Conclusion and What's Next 307 Without attempting to fundamentally change the guidelines within RFC 308 5127, this effort should not be as controversial as it has been, if 309 we understand that those networks that need more granular traffic 310 treatments can be configured with more granularity while not 311 violating the needs of other networks that do not wish to be made 312 aware of the increased treatment differences. 314 Everyone involved in this discussion needs to have a clear 315 understanding of the difference points of view within the RFC 4594 316 effort (i.e., the RFC and the update draft) as well as within RFC 317 5127. One focuses on defining each service class and the other 318 focuses on determining which of the existing service classes go into 319 which aggregate, if present. 321 We hope to form a BoF on this subject that will explicitly *not* 322 form a working group or produce any documents, or even drafts, but 323 will gather the community from several (if not all) areas, and not 324 just within the transport area. That is the purpose of this draft: 325 to stimulate discussion towards the goal of discussion within the 326 community on DiffServ. If the community does not believe a BoF is 327 necessary, the work will proceed, or not, in TSVWG. Knowing how many 328 within the community have attended TSVWG in each meeting for the 329 last 9 or so years, it is felt that a much wider audience is 330 necessary, given how much impact [ID-4594-UPDATE] can potentially 331 have. 333 5. Acknowledgements 335 The author would like to thank Gorry Fairhurst and David Black for 336 their positive discussions towards the formation of a BoF in 337 Vancouver IETF. The author would also like to thank Paul Jones for 338 doing a valuable proof read to catch points I didn't make clear, as 339 well as identify simple nits I should have caught the nth time I 340 reread this. 342 6. IANA Considerations 344 There are no IANA considerations as a result of this document. 346 7. Security Considerations 348 There are no security considerations within this document because it 349 will not be progressed beyond this individual contributor stage, and 350 all the specifying will be done in other drafts that will wholly 351 contain all the security considerations for this goal/idea. 353 8. References 355 8.1 Normative References 357 There are no normative references within this document. 359 8.2. Informative References 361 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 362 Differentiated Services Field (DS Field) in the IPv4 and 363 IPv6 Headers ", RFC 2474, December 1998 365 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 366 Jacobson, "RTP: A Transport Protocol for Real-Time 367 Applications", STD 64, RFC 3550, July 2003. 369 [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for 370 Diffserv Service Classes", RFC 4594, August 2006 372 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 373 DiffServ Service Classes", RFC 5127, February 2008. 375 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 376 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, 377 May 2010 379 [ID-4594-UPDATE] J. Polk, "Standard Configuration of DiffServ Service 380 Classes", "work in progress", March 2012 382 [ID-NEW-DSCPS] J. Polk, "New Differentiated Services Code Point 383 Assignments for Rich Media Traffic", "work in progress", 384 March 2012 386 [ID-TCMTF] J. Saldana, D. Wing, J. Fernandez Navajas, Muthu A M. 387 Perumal, J. Ruiz Mas, "Tunneling Compressed Multiplexed 388 Traffic Flows (TCMTF)", "work in progress", March 2012 390 Authors' Address 392 James Polk 393 3913 Treemont Circle 394 Colleyville, Texas 76034 396 Phone: +1.817.271.3552 397 Email: jmpolk@cisco.com