Network Working Group John Harper Internet-Draft Anagran Inc Patrick McGeer Hewlett Packard Corp January 2007 Requirements for In-Band QoS Signalling Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 19th, 2007. Abstract This document describes the raionale and requirements for in-band signalling of Quality of Service (QoS) characteristics for the Internet Protocol (IP) There has been extensive work on QoS for IP, leading to the development of RSVP, NSIS and other protocols. New requirements emerging from the use of IP to carry services such as video and voice are leading in turn to additional requirements for QoS signalling. The authors believe that these can best be met by adding in-band signalling to IP, complementing the existing protocols for QoS signalling. Copyright Notice Harper & McGeer Expires July 19th, 2007 [Page 1] Internet-Draft Requirements for In-Band QoS Signalling January 2007 Copyright (C) The Internet Society. (2007) 1. Introduction The TCP/IP protocol suite was originally designed to support purely best-effort data transmission. As congestion started to become a practical problem, mechanisms were added in TCP to allow end systems to react to congestion and to slow down their transmission accordingly. As quality-sensitive applications began to use TCP/IP, work was undertaken to provide for explicit signalling of QoS requirements, resulting initially in RSVP and later in the start of work on NSIS. RSVP and NSIS are both out-of-band signalling protocols, i.e. the signalling flow takes place over a separate packet flow from the information itself. This works well for some classes of applications, such as the establishment of MPLS tunnels for traffic engineering. The TCP/IP protocol suite is increasingly becoming a universal way to move all kinds of information, including those which have previously relied on dedicated analog or digital circuits, such as voice and video. Some of these have more stringent quality requirements than traditional data traffic, requiring a certain minimum bandwidth and maximum delay variance ("jitter") if the user requirements are to be met. Where large numbers of sessions are involved, for example when providing domestic video services, it is difficult to design equipment such that out-of-band protocols can operate quickly enough. TCP´s ability to react to network congestion, and hence adapt its transmission speed to available capacity, depends heavily on the fact that in traditional data networks, packet loss due to transmission errors is a rare event. It also depends on gradual ramp-up to the available capacity, using the "slow-start" technique. These have both been appropriate for the networks which have predominated until recently, where links are provided by optical or electrical means and where the bandwidth required for an individual TCP connection is no more than a few megabits/second. Current technological trends mean that these assumptions do not necessarily apply any longer. Wireless links are becoming commonplace. These have significant error rates, enough to force TCP into low throughput as it incorrectly reacts to lost packets as though they signal congestion. This is particularly serious when the wireless links have high bandwidth, for example in the case of third and fourth generation mobile systems. Bandwidths available to all classes of user are steadily increasing. For example, domestic users in many parts of Asia now have access rates of 45 or 100 Mbit/sec. Commercial and industrial users are now often connected via links having instantaneous bandwidth of 100 Mbit/sec or 1 Gbit/sec. TCP slow-start and TCP´s reaction to Harper & McGeer Expires July 19th, 2007 [Page 2] Internet-Draft Requirements for In-Band QoS Signalling January 2007 occasional packet loss mean that practical achievement of these kinds of bandwidths will often not occur. In order to achieve these bandwidths, especially in the presence of errors, explicit signalling of available bandwidth in the network is required. For all the above reasons, it is considered desirable to add means to the TCP/IP protocol suite to allow efficient signalling of QoS requirements and availability in close association with the IP traffic itself. While this could in principle be done using out-of- band signalling, the scale of the signalling to be undertaken makes it harder to achieve the necessary responsiveness and performance by this means. Additionally, in high-speed routers and switches, signalling at the envisaged scale must be performed in hardware if the performance is to be achieved. This is simpler if an in-band signalling protocol, with a simple and well-structured format, is used. In the remainder of this draft, we present specific rationale for an in-band QoS signalling protocol, and set out the requirements that must be achieved by the architecture and the corresponding protocol. 2. QoS Service Goals 2.1 Definition of a Flow In the remainder of this document, the term "flow" is used to mean a sequence of packets belonging to the same host-to-host association, typically either a TCP connection, or where a connectionless transport protocol is in use, a sequence of packets corresponding to the same information stream. In an IPv4 network, a flow is generally considered be a sequence of packets sharing the same source and destination IP addresses, transport protocol and transport protocol source and destination ports (if applicable). In an IPv6 network, a flow is a sequence of packets sharing the same source and destination IP addresses and the same Flow Identifier. The presence of the Flow Identifier in IPv6 means that inspection of transport layer port information is not required in order to determine flow membership. However this does depend upon the consistent use of the Flow Identifier. It is also possible to make explicit use of transport layer port information, if IPv6 payload encryption is not in use. 2.2 Types of Flow IP applications can be broadly divided into two categories, when considering QoS: - those that will use whatever bandwidth is available, adjusting their rate accordingly. Such applications normally run over TCP (or Harper & McGeer Expires July 19th, 2007 [Page 3] Internet-Draft Requirements for In-Band QoS Signalling January 2007 other connection-mode transport protocols such as SCTP). Flows having this characteristic are called AR ("Available Rate") flows. Because available capacity in the network is constantly changing, AR flows need to be able to receive periodic updates about the current capacity, so they can change their behavior. - those that have a predetermined bandwidth requirement, which may be fixed or may vary. If the required bandwidth is not available then the service as seen by the user deteriorates and may become completely unusable. Applications such as voice and streaming video fall into this class. These applications can in turn be divided into three categories, as described below. GR - Guaranteed Rate service specifies a reserved rate and is intended for those cases where bandwidth must be reserved by the network, even when it is unused. The network should not oversubscribe the allocations for any given preemption level. It requires explicit signalling of reservation and release, which are only used with the Guaranteed Rate service. MR - Maximum Rate service has no fixed reservation. It specifies the maximum rate the flow might use and makes every attempt to assure no packet loss if the flow remains under this rate. The flow may be variable in rate, not to exceed the specified maximum rate. Flows may be policed or shaped to ensure that this rate is not exceeded. Flows may be dropped if it is known to be impossible to deliver the stated maximum rate, for example dut to congestion. Unlike guaranteed rate traffic, the bandwidth is available subject to traffic statistics; it is not an absolute guarantee. The flow is dropped if no traffic is seen for a preset period and so no explicit release is required. The service can be used for individual video, voice or streaming media flows where very low loss and/or low delay jitter is required. VR - Variable Rate service, where part of the rate is guaranteed and part is determined by network capacity (available rate). This is typically the case, when streaming media cannot function below a base rate but can take advantage of additional capacity if it is available. This capability is signaled as a maximum rate plus an available rate. Traffic up to the maximum rate plus the available rate will be supported. The available rate may be changed from time to time as the network capacity changes. 2.3 Other QoS Goals In addition to the bandwidth-related QoS flow attributes described in section 2.1, there are other requirements associated with the service applied to a particular flow. Harper & McGeer Expires July 19th, 2007 [Page 4] Internet-Draft Requirements for In-Band QoS Signalling January 2007 PP - Preemption Priority indicates which flows should survive when the network capacity is insufficient to support the required quality of all the flows. It is necessary to support civilian emergency services, military services, and will also have applications in other aspects of networking. BT - Burst Tolerance specifies how much the actual rate may exceed the stated rate before policing is enforced. This not only applies to rate bursts the user may introduce at the source but is necessary to allow for bunching the network routers may introduce. DP - Delay Priority permits explicit signalling of the relative importance of flows with respect to limiting delay variation. CH - Charge Direction specifies who is paying for this flow, the sender or the receiver. This allows IP to provide 800 type services like the PSTN and allows for peering between networks of different sizes with fair charging. 3. Problems with Current QoS Signalling Techniques 3.1 Diffserv and its Limitations Diffserv provides a Class of Service (COS) marking in 6 bits in the IP header. Only a subset of the 64 possible values has a globally recognised definition. Due to the low range of values, there is no way to have globally unified definitions of the meaning of the codepoints. Also there are too few bits to specify explicitly a rate for either guaranteed rate flows or for available rate feedback. This limits the utility of Diffserv to a few delay categories and some local link-by-link agreements. As we move into video and streaming media as well as improving TCP performance, Diffserv provides insufficient flexibility. 3.2 IntServ and its Limitations The current proposals for IntServ type QoS support (as opposed to CoS support via Diffserv) revolve around a round trip call setup request using complex protocols like RSVP. These protocols require more processing than can be done in hardware and are thus obliged to operate in relativey slow software processes. This limits the total end-to-end call processing that can be made to either very large flows or to composite (VPN) flows since processor speeds are insufficient for processing all IP flows. What is desirable is a protocol that permits the router to process QoS requests for each individual flow, including parameters such as bandwidth, delay priority, preemption priority, burst tolerance, and Harper & McGeer Expires July 19th, 2007 [Page 5] Internet-Draft Requirements for In-Band QoS Signalling January 2007 charging direction. Many common flows like file transfers may not require all this information. However, increasingly flows are becoming voice, video, gaming, or streaming media where such requirements do apply. Also, as the IP becomes the predominant protocol for the provision of voice and emergency communications, the need for call rejection and preemption priority become important and may even be life and death issues. These capabilities are therefore required as part of the IP protocol, for both TCP and UDP. 3.3 Issues Regarding TCP TCP slow-start has worked well over the past 20 years when the individual flows were generally in the kilobits/second. However, as wideband corporate access and broadband residential access have proliferated, the desired flow rate has increased into the megabits/second up to several gigabits/second. TCP was not designed for these rates at any significant distance. TCP depends on detecting packet loss to adjust its rate; any packet loss at high rates over long distances creates a major slow down of the flow. Even at normal cross-country distances, maximum TCP throughput is limited to megabits/second rather than gigabits/second. The performance of TCP when operating over satellite links is poor enough that TCP "spoofing" devices are frequently used at either end of any satellite link. However, this will not work when the data is encrypted as in IPv6, in IPv4 with IPSEC or in either with encryptors inserted. Another problem with using packet loss as a rate control mechanism is that the typical method of dealing with congestion is to discard random packets, even if the flow in question is not yet up to the speed of other flows. This is usually done using Random Early Detection (RED) or Weighted Random Early Detection (WRED). This procedure slows down the TCP rate so that it does not get up to the maximum network speed as fast as possible. This problem has been magnified as the network speeds have increased such that an average 120 K byte web page transfer over a 10 Mbps access line can take many seconds rather than the fraction of a second actually required. The TCP situation is improved by marking packets for congestion, using Explicit Congestion Notification (ECN) before discarding becomes necessary. ECN avoids discarding the packet, but the search for the rate the network can support is still a binary search that leads to significant loss of throughput and does not improve the slow-start problem. Marking packets in this way, also presumes that the network has sufficient storage to signal congestion well before Harper & McGeer Expires July 19th, 2007 [Page 6] Internet-Draft Requirements for In-Band QoS Signalling January 2007 the problem becomes critical. This in turn leads to either additional network delays due to long queue traversals, or exacerbates the existing problem of lower network utilization. When the concept of marking packets is coupled with the feedback of the maximum rate the network could support, it is feasible for the TCP source to avoid slow-start and achieve extremely high-speed throughput. Instead of marking or discarding packets when congestion occurs, the network can inform all TCP sources as soon as possible of the rate that they can operate at safely. As conditions change, additional feedback is required. This concept was simulated and tested extensively in ATM systems. It was found to substantially decrease the time to transfer a web page and significantly decrease the buffering required in the network. 3.4 Considerations for Streaming Protocols While many applications use TCP, there are others which do not require the benefits it brings with regard to error recovery, reordering and flow control. Such applications typically use UDP as a connectionless transport protocol. In particular, real-time streaming applications such as video and voice operate in this way. These applications are not, in general, able to adjust their transmission rate in response to the capacity of the network. For example, an uncompressed voice flow using G.711 encoding requires a bandwidth of 64 kbit/sec for the voice payload. Similarly, real-time compressed video typically requires a bandwidth in the range 2-6 Mbit/sec, depending on the encoding and the content. A given flow will simply not work if the available bandwidth turns out to be less than this. (There are approaches to dealing with this, for example by switching to a lower-rate codec with lower quality, but they require an additional management layer and also require explicit knowledge of the available bandwidth, unlike TCP which adjusts continuously). Hence, if the total bandwidth available is enough to support say 100 such flows, and another one presents itself, it is better to block the new flow, than to accept it and downgrade the quality of the service provided to all 101 users. The capability to control admission in this way is referred to as Call Admission Control (CAC). RSVP was designed to perform admission control, but the limited practical experience with RSVP as a generic admission control protocol shows that it does not scale to handle very large numbers of individual flows. It is adequate for handling aggregated flows (for example, VPN connections through a service provider network) but not for handling individual flows. 3.5 Protocol Complexity and Hardware Processing Harper & McGeer Expires July 19th, 2007 [Page 7] Internet-Draft Requirements for In-Band QoS Signalling January 2007 A high-speed router, operating at link speeds of 1 Gbit/sec or higher, will handle a very large number of flows and flow-setup operations. If many of those flows include explicit QoS signalling, the handling of this signalling needs to be performed at very high speed. In a practical implementation, this means that it must take place in the data plane and be performed by the same system elements that perform packet forwarding operations, i.e. hardware logic implemented in an ASIC or programmable logic, or in code executed in special-purpose Network Processors (NPUs). This logic or code is highly optimised and is not amenable to the kinds of operations typically performed in general-purpose CPUs by software. In considerations of protocol design, this means that the QoS signalling protocol should have a simple fixed structure. The very flexible structures used in existing QoS signalling protocols, such as type- length-value encoding supporting a multiplicity of optional features, cannot be implemented in hardware or NPU-based systems. 4. Implications for Signalling Protocol Design 4.1 Benefits of In-band Signalling Signalling of QoS requirements can in principle be effected using either out-of-band signalling, like RSVP, or in-band signalling. To date, there has been no implementation of RSVP which can perform large numbers of flow-setup operations at a high rate, which suggests that such an implementation would be difficult. In-band signalling, using a simple protocol, has the following benefits in addition to those described above. 1. In-band signalling is guaranteed to follow the same path through the network as the flow on whose behalf it is signalling. This is very difficult to achieve for an out-of-band protocol, taking into account realities of network design such as equal cost multipath routes. 2. Since in-band signalling is carried along with the payload of the flow, it is unaffected by en-route changes to network addressing such as NAT. In principle an out-of-band protocol can deal with this, but it is a complex problem which has been under study in the IETF (MidCom) for several years. 3. Accurate detection of congestion in the network requires frequent updates about the available capacity. A simple protocol carried along with the payload can provide this through an efficient data-plane implementation. Given the difficulty of scaling current out-of-band protocols to handle large numbers of flows, it would be even harder to provide frequent real-time updates about the state of the network. Harper & McGeer Expires July 19th, 2007 [Page 8] Internet-Draft Requirements for In-Band QoS Signalling January 2007 4.2 Requirements for an In-band Signalling Protocol From the above considerations, the following requirements apply to an in-band protocol for QoS signalling. 1. The protocol MUST be carried within packets which form part of the flow for which QoS information is being conveyed. This is inherent in the nature of an in-band protocol. 2. The protocol MUST be capable of operating with both IPv4 and IPv6, although variations may be required to make this possible. 3. The protocol MUST provide a means for an AR flow to signal its requested bandwidth, and to receive information from the network about the bandwidth actually available. 4. The protocol MUST provide a means for a GR, MR or VR flow to signal its requested bandwidth. 5. The protocol MUST provide a means to signal other QoS information, specifically Burst Tolerance, Preemption Priority, Delay Priority, and Charging Information. 6. The protocol MUST provide a means for a flow to periodically determine the currently available bandwidth in the network. 7. The protocol MUST provide a means for GR flows to perform explicit bandwidth reservation and release, in a confirmed and reliable way. 8. The protocol MUST define an encoding which lends itself readily to implementation in hardware, programmable logic or high-performance dedicated network processors. 5. Security Considerations A QoS signalling protocol is capable of reserving network resources, or of providing information to a host which will lead it to make use of network resources. The protocol which is defined in support of the requirements decsribed in this document needs to address how such resources can be protected in an appropriate fashion, either through elements of the protocol itself, or through associated configuration of the systems which implement it, or both. 6. Editors´s Addresses John Harper Anagran Inc 2055 Woodside Road Harper & McGeer Expires July 19th, 2007 [Page 9] Internet-Draft Requirements for In-Band QoS Signalling January 2007 Redwood City, CA 94065 USA Phone: +1 650 587 8276 EMail: john@anagran.com Patrick McGeer Hewlett-PAckard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 USA Email: rick.mcgeer@hp.com This Internet-Draft will expire on July 19th, 2007. 7. Full copyright statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Harper & McGeer Expires July 19th, 2007 [Page 10]