Network WG James Polk Internet-Draft Cisco Intended status: Informational June 20, 2012 Expires: December 20, 2012 The Problem Statement for the Standard Configuration of DiffServ Service Classes draft-polk-diffserv-stds-problem-statement-01.txt Abstract This document describes the problem statement on two recently proposed expansions to DiffServ. The first of these expansions proposes updating the informational RFC 4594 document to standards track status, while making the necessary changes to make it current; for example, creating more granular traffic treatments, some with new Per Hop Behaviors (PHB). The second proposal defines 6 new DiffServ Codepoints necessary from these new PHBs in the proposal within the first draft. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 20, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Polk Expires December 20, 2012 [Page 1] Internet-Draft Problem Statement for DiffServ Stds June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Brief Overview of RFC 4594 and RFC 5127 . . . . . . . . . . . 3 2.1 Brief Overview of RFC 4594 . . . . . . . . . . . . . . . . 3 2.2 Brief Overview of RFC 5127 . . . . . . . . . . . . . . . . 4 3. Brief Discussion of the RFC 4594 Update Draft . . . . . . . . 5 4. Conclusion and What's Next . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Normative References . . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Differentiated Services (DiffServ) [RFC2474] creates an IP header marking or indicator with which intermediate nodes (i.e., routers and switches) can make policy decisions. These 6-bit values are called Differentiated Services Codepoint Point (DSCP) values. DSCP values are used to differentiate packet treatment within an intermediate node, not across a network, as the conditions affecting that marking are different within each node. This is called Per Hop Behavior (PHB). A packet could have the same DSCP value from source to destination, but the intended mode of operation is for the DSCP value to be rewritten when the packet crosses the boundary of a DiffServ administrative domain. Indeed, the packet may be fully reclassified at a domain boundary. The DSCP value should stay the same only if adjacent domains have agreed to use the same set of DSCP values and the same, or equivalent, PHBs. Inconsistency will arise if a domain does not rewrite the DSCP value when receiving a packet from another domain that uses a different set of DSCPs and PHBs. At issue is a combination of the number of networks or endpoints that are choosing to use DiffServ markings, and the number of administrative domains (called "networks" in this document) a packet traverses with different policies for how packet flows of a similar type (e.g., a voice flow, or an email flow, etc.) are to be marked. The community presently has RFC 4594 [RFC4594], which is an informational guideline on how networks can or should mark certain packet flows with differing traffic characteristics using DiffServ. There are several reasons why this informational RFC lacks the necessary clarity and strength to reach widespread adoption: o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of which is for aggregating many 6-bit DSCP values into the 3-bit (8 Polk Expires December 20, 2012 [Page 2] Internet-Draft Problem Statement for DiffServ Stds June 2012 value) field available in MPLS. This confusion arises because RFC 5127 is written in general terms, and indeed aggregation could be used on non-MPLS paths, but the specific restriction to 3 bits is due entirely to MPLS and only applies to the MPLS portion of a packet's path. A similar 3-bit field exists within IEEE's 802 specifications, which causes the same confusion. o some believe both RFCs are for SPs, while others ignore RFC 5127 and use RFC 4594 as if it were standards track or BCP. o some believe RFC 5127 is for SPs only, and want RFC 4594 to reduce the number of DSCPs within its guidelines to recommend using only 3 or 4 DSCPs. This seems to stem from a manageability and operational perspective. o some know RFC 4594 is informational and do not follow its guidelines specifically because it is informational. o some use DSCP values that are not defined within RFC 4594, making mapping between different networks using similar or identical application flows difficult. o some believe enterprise networks should not use either RFC except at the edge of their networks, where they directly connect to SP networks. o some argue that the services classes guidance per class is too broad and are therefore not sure in which service class a particular application is to reside. This document is not intended to reach RFC status. Rather, it is to stimulate discussion on both RFC 4594 and 5127 to lessen existing confusion within the community. It should be noted that RFC 4594 has an offered update within TSVWG [ID-4594-UPDATE]. This draft has created some heated discussions within that WG before and during the Paris IETF meeting. First, we'll discuss briefly RFCs 4594 and 5127 in Section 2. Then we will discussion what the update to RFC 4594 proposes differently and what we expect to happen to RFC 5127 in Section 3. 2. Brief Overview of RFC 4594 and RFC 5127 2.1 Brief Overview of RFC 4594 Essentially, RFC 4594 is a guideline for how to choose which DSCP to use based on the traffic characteristics an application flow needs to experience within a network for optimal performance. RFC 4594 specifically points to several existing standards-track DiffServ RFCs to augment the text in each of those RFCs, without violating Polk Expires December 20, 2012 [Page 3] Internet-Draft Problem Statement for DiffServ Stds June 2012 any of the rules within each of those documents. RFC 4594: o painstakingly lays out definitions and guidelines for each service class. o clearly indicates each service class's tolerance to delay, jitter and packet loss. o details the conditioning treatments at the Differentiated Services (DS) edge. o categorizes traffic characteristics into 12 service classes utilizing one or more DSCPs: Network Control Broadcast Video Telephony Low-Latency Data Signaling OAM Multimedia Conferencing High-throughput Data Realtime Interactive Standard Multimedia Streaming Low-priority Data 2.2 Brief Overview of RFC 5127 At its barest, RFC 5127 recommends that, of the many service classes described within RFC 4594, each having different traffic characteristics, similar service classes be grouped or aggregated into 3, 4, or 5 markings for SP traversal. This limitation of the number of individual service classes is partly to reduce the number of separate distinctions traversing over their network because SPs have difficulty managing what is deemed 'too many' different classes. Another part for this reduction is customer expectations of meeting contractual Service Level Agreements (SLAs). To this end, and perhaps because of it, MPLS was designed with only 8 values of priority differentiation, i.e., the 3 EXP bits. To be fair, LAN based IEEE has only a 3-bit priority field as well within its specifications, known as the Priority Code Point (PCP), as part of the 802.1Q header spec. IEEE 802.1e, which defines QoS over Wi-Fi, also only defines 8 levels (called User Priority or UP codes). The result is to have the IETF within RFC 5127 recommend the following (which is Figure 2 within that RFC): Polk Expires December 20, 2012 [Page 4] Internet-Draft Problem Statement for DiffServ Stds June 2012 ------------------------------------------------------------ |Treatment |Treatment || DSCP | |Aggregate |Aggregate || | | |Behavior || | |==========+==========++=====================================| | Network | CS || CS6 | | Control |(RFC 2474)|| | |==========+==========++=====================================| | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | | Time |(RFC 3246)|| | |==========+==========++=====================================| | Assured | AF || CS2, AF31, AF21, AF11 | | Elastic |(RFC 2597)||-------------------------------------| | | || AF32, AF22, AF12 | | | ||-------------------------------------| | | || AF33, AF23, AF13 | |==========+==========++=====================================| | Elastic | Default || Default, (CS0) | | |(RFC 2474)||-------------------------------------| | | || CS1 | ------------------------------------------------------------ Figure 1: Treatment Aggregate Behavior RFC 5127 goes on to recommend the marking and treatments on either side of the provider edge remain the same. In other words, the DSCP values remain the same and are used to determine which queue to place the packets into within the aggregates, where the packets are treated the same within that tunnel until the egress provider edge. Many within enterprise networks do not pay attention to what RFC 5127 says because they are sufficiently removed from dealing with the constraints of very few DSCP values or the need to aggregate DSCP values into groups. 3. Brief Discussion of the RFC 4594 Update Draft The RFC 4594 update draft [ID-4594-UPDATE] proposes to update what has occurred since RFC 4594 was written (i.e., 2006), in which more granular service classes can be differentiated by application requirements. For example, Figure 2 within RFC 4594 identifies "Telephony" as having 'Fixed-size small packets'. That is not true for today's video flow, therefore it needs to be modified. The update draft currently breaks out audio and video separately to reflect this different, as well as the ability to treat each traffic type differently within a network. Another example is gaming and TCP. The two were believed by most, and it is still believed by many that gaming requires a UDP delivery due to the requirements for timely delivery of packets and that retransmissions would cause delays and bad things to happen to gaming applications. This was proved false within [ID-TCMTF], in which the author of that document Polk Expires December 20, 2012 [Page 5] Internet-Draft Problem Statement for DiffServ Stds June 2012 had a presentation showing TCP was used and viable. [RFC5865] created a new Expedited Forwarding (EF) DSCP value called VOICE-ADMIT, the second time an application is identified within the DiffServ realm. The first was the service class Broadcast Video, which is poorly used within RFC 4594 because other types of flows can be 'broadcast' other than video, such as audio. From this, [ID-4594-UPDATE] moved in two directions: o it called out two service classes (audio and video), even though audio and video packets are not the only types of packets within each traffic characteristic. o it removed "Video" from the Broadcast service class name. From the resistance to this proposal within [ID-4594-UPDATE], perhaps other service class label names should be used. The draft also recognizes the differences in video traffic, even though it is always carried over RTP [RFC3550]. Aside from silence suppression, video traffic varies far more than audio traffic. For example, video is o far more variable in bandwidth utilization within the same flow. o far more variable in packet size. o at different business priorities in some networks based on a configuration. For example, desktop video often is of less important than Telepresence video on the same network. Lacking congestion, the two are treated the same. When congestion exists, one is given priority over the other. Consequently any service class that contains video needs to account for larger packet size variation than audio, which was equally true in 2006, but not contained in RFC 4594. Further, with the publication of RFC 5865, the concept of 'capacity admitted' traffic flows have been defined within DiffServ, and are being expanded with the proposal within this new draft [ID-NEW-DSCPS]. There are differing opinions as to whether the realtime Treatment Aggregate in Figure 1 above should also contain these capacity admitted flows, or if 'capacity admitted' traffic flows should have their own Treatment Aggregate containing all realtime capacity admitted traffic. Mixing capacity admitted traffic with unbounded realtime traffic seems to be trouble from a predictability point of view within routers believing they individually understand exactly how much traffic will be traversing each interface and at what rate. All this said, there is a valid argument to constrain or prevent any DSCP value from being assigned to a single application, mostly due Polk Expires December 20, 2012 [Page 6] Internet-Draft Problem Statement for DiffServ Stds June 2012 to the limitation of the overall number of DSCP values available for use. [ID-4594-UPDATE] provides at least several applications per service class (or DSCP); a fact many have overlooked to date. [ID-4594-UPDATE] is not only about or because of realtime traffic. It is also an overall update to the ideas and guidelines within RFC 4594, with the intent to make that document a standards track document for interoperability purposes. As a result, the 12 service classes of unique traffic characteristics from RFC 4594 have been changed and increased to 14, as shown below Network Control Multimedia Streaming Realtime Interactive Low-Latency Data Audio Conversational Signaling Video High-throughput Data Hi-Res A/V OAM Multimedia Conferencing Standard Broadcast Low-priority Data 4. Conclusion and What's Next Without attempting to fundamentally change the guidelines within RFC 5127, this effort should not be as controversial as it has been to date. If we understand that enterprise networks, or any networks for that matter, that need more granular traffic treatments can be configured in a consistent way with more granularity while not violating the needs of other networks, mostly SP networks, that do not wish to be made aware of the increased treatment differences. Everyone involved in this discussion needs to have a clear understanding of the difference points of view within the RFC 4594 effort (i.e., the RFC and the update draft) as well as within RFC 5127. One focuses on defining each service class specific to the differences in traffic characteristics necessary for an application and the other focuses on determining which of the currently configured service classes go into which treatment aggregate. Once the community re-understands the difference between RFC 4594 (to define separable traffic treatments and mark each differently) and RFC5127 (to aggregate these many separate markings where necessary, and in a fairly uniform manner), the authors will forge ahead with proposing the increase in the number of discrete traffic characteristics requiring different markings, which is the subject of the RFC4594-update effort. The discussion about whether or not 'audio' and 'video' should be named service classes should occur once there is a clearly understood difference between the two RFC's goals. We hope to form a BoF on this subject that will explicitly *not* Polk Expires December 20, 2012 [Page 7] Internet-Draft Problem Statement for DiffServ Stds June 2012 form a working group or produce any documents, or even drafts, but will gather the community from several (if not all) areas, and not just within the transport area. That is the purpose of this draft: to stimulate discussion towards the goal of discussion within the community on DiffServ. If the community does not believe a BoF is necessary, the work will proceed, or not, in TSVWG. Knowing how many within the community have attended TSVWG in each meeting for the last 9 or so years, it is felt that a much wider audience is necessary, given how much impact [ID-4594-UPDATE] can potentially have. 5. Acknowledgements The author would like to thank Gorry Fairhurst and David Black for their positive discussions towards the formation of a BoF in Vancouver IETF. The author would also like to thank Paul Jones for doing a valuable proof read to catch points I didn't make clear, as well as identify simple nits I should have caught the nth time I reread this. Thank you to Brian Carpenter for clarifying a few points made in the original version of this document. 6. IANA Considerations There are no IANA considerations as a result of this document. 7. Security Considerations There are no security considerations within this document because it will not be progressed beyond this individual contributor stage, and all the specifying will be done in other drafts that will wholly contain all the security considerations for this goal/idea. 8. References 8.1 Normative References There are no normative references within this document. 8.2. Informative References [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers ", RFC 2474, December 1998 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for Polk Expires December 20, 2012 [Page 8] Internet-Draft Problem Statement for DiffServ Stds June 2012 Diffserv Service Classes", RFC 4594, August 2006 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", RFC 5127, February 2008. [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010 [ID-4594-UPDATE] J. Polk, "Standard Configuration of DiffServ Service Classes", "work in progress", March 2012 [ID-NEW-DSCPS] J. Polk, "New Differentiated Services Code Point Assignments for Rich Media Traffic", "work in progress", March 2012 [ID-TCMTF] J. Saldana, D. Wing, J. Fernandez Navajas, Muthu A M. Perumal, J. Ruiz Mas, "Tunneling Compressed Multiplexed Traffic Flows (TCMTF)", "work in progress", March 2012 Authors' Address James Polk 3913 Treemont Circle Colleyville, Texas 76034 Phone: +1.817.271.3552 Email: jmpolk@cisco.com Polk Expires December 20, 2012 [Page 9]