Internet Engineering Task Force Salil Talauliker INTERNET DRAFT Cory Beard Expires: December 2002 Univ. of Missouri-Kansas City June 2002 Internet Emergency Preparedness Services in a Differentiated Services Domain Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 made obsolete 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. Abstract The international community needs advice as to what standards to rely on for the operational implementation of services for Emergency Preparedness. This draft outlines the best current practices to provide deterministic behavior of Internet applications during emergencies using Differentiated Services. It should be noted that there can be more than one suitable approach and this draft only describes what can be done with the existing Differentiated Services architecture. Table of Contents 1. Introduction...................................................2 2. Priority Treatment using Diffserv AF PHB.......................3 2.1 Assured Forwarding Per Hop Behavior........................3 3. Queue Scheduling and Management Methods........................3 4. Random Early Detection.........................................5 5. Multi-level RED................................................5 Talauliker & Beard Expires - December 2002 [Page 1] Internet-Draft IEPREP in a Diffserv Domain June 2002 5.1 Evaluation of MRED Variants................................6 5.2 Multiple Average Multiple Threshold Techniques.............6 6. Mapping RED to Emergency Traffic...............................7 7. Conclusion.....................................................7 8. Security Considerations........................................8 References........................................................8 Author's Addresses................................................9 1. Introduction This document outlines the best current practices for the operational implementation of priority services in IP-based networks to enable communications for National Security/Emergency Preparedness (NS/EP) operations. These services seek to return the population to normal living conditions after serious disasters and events, such as floods, earthquakes, hurricanes, and terrorist attacks [2]. This draft focuses on communication between priority users that include one-to- one or group level communications using Internet telephony, email, chat and government informational web sites. At the time of this writing there is no standard document, which identifies a Priority User. Hence for the purpose of this document priority users include the following [1]: o National Security/Emergency Preparedness (NS/EP) users - Those who prepare for and respond to natural disasters or man-made disasters. o Military users of the public Internet. o E-911 users - People who look to use the public Internet to contact emergency organizations. o Anyone - Given the right context and function to be performed, anyone can conceivably be considered high priority It is important to note that priority users do not necessarily expect high quality of service (e.g., low delay, high data rates). However, they expect network services to be available to them and to perform reliably, regardless of the state of the network or the context in which it is operating (e.g., after a natural disaster). This draft describes mechanisms for end-to-end treatment of priority users through Differentiated Services domains that explicitly support priority users. This draft assumes that some form of marking and identification mechanism will be used to differentiate the traffic Talauliker & Beard Expires - December 2002 [Page 2] Internet-Draft IEPREP in a Diffserv Domain June 2002 generated by high priority users from the traffic generated by normal users. However such a mechanism is not yet standardized. This draft is organized as follows: Section 2 discusses the use of the Diffserv AF PHB for priority treatment. Section 3 identifies and compares the existing queuing mechanisms with the objective of providing priority treatment. Section 4 gives and overview of random Early Discard. Section 5 discusses the use of RED variants for the purpose of priority treatment. Section 6 talks about the idea of mapping MRED techniques to emergency traffic. 2. Priority Treatment using Diffserv AF PHB The Differentiated Services (DS) [3] architecture has become the preferred method to address Quality of Service (QoS) issues in IP networks. This packet marking based approach to IP-QoS is attractive due to its simplicity and ability to scale. An end-to-end differentiated service is obtained by concatenation of per-domain differentiated services. DS domain refers to a contiguous set of nodes, which operate with a common set of service provisioning policies and Per Hop Behavior (PHB) definitions. Per domain services are realized by traffic conditioning [3] at the edge and simple differentiated forwarding mechanisms at the core of the network. Two forwarding mechanisms standardized by IETF are the Assured Forwarding (AF) [4] and Expedited Forwarding (EF) [5] Per Hop Behavior. 2.1 Assured Forwarding Per Hop Behavior The Assured Forwarding (AF) [4] PHB is a very suitable approach for providing priority treatment to Internet traffic. The AF PHB RFC specifies four classes and three levels of drop precedence per class. The different drop precedence levels are also referred in terms of colors as Green û DP0, Yellow û DP1, Red û DP2. In case of congestion, an AF-compliant DS node drops low precedence (red) packets in preference to higher precedence (green, yellow) packets. Multiple levels of drop precedence can be used to achieve fair allocation of excess network bandwidth among congestion sensitive TCP and insensitive UDP flows. Depending on the QoS requirements and the level of emergency, traffic flows from priority users can be assigned to one of these four classes and within each class can be assigned an appropriate drop precedence. 3. Queue Scheduling and Management Methods Once the priority traffic is colored by the traffic conditioner and assigned to suitable AF queues the next step is to service the queues. Queue scheduling techniques could be broadly classified into Talauliker & Beard Expires - December 2002 [Page 3] Internet-Draft IEPREP in a Diffserv Domain June 2002 Preemptive and Non-preemptive scheduling. In non-preemptive scheduling, a packet leaves the queue only when it has been serviced by the router. In preemptive scheduling, a packet could be discarded while it is waiting to be serviced if a higher priority packet arrives. Shown below is a hybrid list of some of the existing queue scheduling and management schemes that can be used. The first four are queue scheduling methods, which determine how packets get access (i.e., are scheduled) to use the outgoing link. The fifth method, RED, is classified as a queue management method which only ômanagesö the queue. Each of them have certain merits and demerits and hence a tradeoff exists while selecting an appropriate queuing scheme for providing priority services. O First In First Out (FIFO): This is a standard queuing technique, which is least processor intensive. However this scheme cannot give any priority treatment to emergency traffic. O Priority Queuing (PQ): This is designed to provide strict priority handling of identified data streams. Generally the traffic is segregated into one of 4 queues and the lower queues are serviced only when the upper queues are empty. This scheme would provide a QoS, which is better than what is needed for emergency traffic. However it does so at the cost of transferring the delay from the high priority queue to the lower priority queues and eventually the lower priority queues may starve. O Class Based Queuing (CBQ): This scheme works by setting a specified access rate to each of a number of custom queues. The queues are served in a round-robin fashion, which ignores priority classifications. CBQ should be used when an equal fair-share of the bandwidth must be maintained. O Weighted Fair Queuing (WFQ): This is generally the most recommended step beyond FIFO. WFQ involves a series of competing queues with priorities set by IP Precedence values and length of packet. The queuing algorithm adjusts to try to keep from starving some traffic types while maintaining the higher priority traffic. The number of queues is not fixed and can adjust to the environment. In essence WFQ is a compromise strategy between Priority Queuing, which can indiscriminately starve out non-priority traffic, and Custom Queuing, which maintains fixed traffic classes. Talauliker & Beard Expires - December 2002 [Page 4] Internet-Draft IEPREP in a Diffserv Domain June 2002 O Random Early Detection (RED) [6]: This is a form of Active Queue Management (AQM) [7] technique where routers detect incipient congestion by computing the average queue size. It is different from conventional queue scheduling techniques mentioned above since it focuses on queue memory and uses packet drops to limit bandwidth usage. However, it is the most favored approach for implementing AF. 4. Random Early Detection RED is an active queue management technique currently deployed in large IP networks. When the average queue size exceeds a preset threshold, the router drops or marks each arriving packet with a certain probability, where the exact probability is a function of the average queue size. With RED, the dropping of a single packet is enough to signal congestion to host transport-layer protocols. By discarding a single packet, a router sends an implicit warning to a source TCP that the discarded packet experienced congestion at some point along the end-to-end path to the destination TCP. As a response to this implicit warning, the source TCP is expected to reduce its transmission rate (by returning to slow-start or fast recovery with congestion avoidance) so that the routerÆs queue buffer does not overflow. RED-enabled routers keep the average queue size low while allowing occasional bursts of packets in the queue. During congestion, the probability that the router notifies a particular connection to reduce its window is roughly proportional to that connectionÆs share of the bandwidth through the router. RED routers are designed to accompany a transport-layer congestion control protocol such as TCP. The most important advantage of AQM is that it avoids the global synchronization of many connections decreasing their window at the same time. RED also helps to solve the issue of controlling aggressive flows that do not throttle back upon receiving congestion notification. There is a growing use of the Internet by these UDP-like applications that introduce unresponsive flows or flows that are responsive but are non-TCP-compatible [7] whose congestion avoidance algorithms are inadequate or nonexistent. These flows pose a significant threat to Internet performance. Using RED can lessen or remove the impact of these flows. 5. Multi-level RED Of great interest to Emergency Services is Multi-level RED (MRED) [8], which is a RED configuration where multiple sets of RED Talauliker & Beard Expires - December 2002 [Page 5] Internet-Draft IEPREP in a Diffserv Domain June 2002 parameters are applied against different colored packets in the same queue. MRED is a generic term used to describe any scheme where drop probability for packets needs to be calculated independently for each drop precedence. This is achieved by maintaining multiple sets of RED thresholds û one for each drop precedence. In addition, the average queue used in the drop decision can be calculated using a number of different schemes. In [9], Goyal et al classifies variants of RED into 4 categories: O Single Average Single Threshold (SAST) e.g. RED. O Single Average Multiple Threshold (SAMT) e.g. WRED. O Multiple Average Multiple Threshold (MAMT) e.g. RIO-C,RIO-DC. O Multiple Average Single Threshold (MAST) 5.1 Evaluation of MRED Variants An AF queue implemented with SAST would calculate a single average queue size that includes arriving packets of all colors and would have only one threshold parameter. Obviously this technique cannot provide any differentiation between normal and priority traffic and is infeasible for implementing emergency services. However the SAMT and MAMT variants have more granularity in the calculation of average queue sizes and threshold parameters. WRED still does not differentiate between Red, Green or Yellow color while calculating the average queue size. But since it uses multiple thresholds for different colors it can provide differentiated treatment to priority traffic. 5.2 Multiple Average Multiple Threshold Techniques The MAMT technique, which uses RED with In/Out (RIO), provides an ideal solution. RIO has two variants û RIO with Coupled virtual queues (RIOûC) and RIO with De-coupled virtual queues (RIO-DC). RIO uses the same mechanism as in RED, but is configured with two sets of parameters, one for IN packets and one for OUT packets. The packets of a traffic stream are marked in-profile (IN) when the stream is within the limits of specified policy. When the stream crosses the limits of the specified policy, its packets are marked as out-of- profile (OUT) packets. IN and OUT correspond to DP0 and DP1 or green and yellow packets. However, RIO-C [10] can be easily extended to three-drop precedence or colors [11]. RIO-C with three DPÆs is called Generalized RIO-C. Talauliker & Beard Expires - December 2002 [Page 6] Internet-Draft IEPREP in a Diffserv Domain June 2002 In GRIO-C, the average queue for packets of different colors can be calculated by adding its average queue to the average queues of colors of lower drop precedence. For example, for red packets, the average queue will be calculated using red, yellow and green packets. In RIO-DC [12], the average queue for packets of each color is calculated using number of packets of that color in the queue. The average queue length for green, yellow and red packets will be calculated using the number of green, yellow and red packets in the queue respectively. Computing parameters with RIO-DC technique gives much finer control over the treatment of priority traffic. Preliminary simulation experiments [8] have shown that for ON-OFF traffic, RIO-C is better able to protect DP0 packets than WRED regardless of the RED model used. For traffic with characteristics of transactional transfer, it is found that RIO-C is able to offer better transactional rate per second regardless of the RED model used. Both RIO-C and WRED offer greatest protection for DP0 packets when the staggered RED parameter model is utilized. WRED needs to have larger thresholds than RIO-C before it can protect DP0 packets. 6. Mapping RED to Emergency Traffic The RIO scheme described above is highly suitable for treatment of emergency traffic in a Diffserv domain. Depending on the SLA the traffic conditioner can mark the traffic for priority treatment in the Diffserv domain. What policy would be used to mark the packets and which of the four AF queues these packets would be assigned to is still an open question. An example scheme for such configuration is given in [13]. 7. Conclusion Based on this discussion of best current practices the following recommendations are made to the IETF and the NS/EP service providers: The traffic conditioner [3] used at the ingress router in a Diffserv domain would mark the incoming flows with appropriate AF/EF codepoints. The traffic from Emergency sources would be marked with low drop precedence colors. A standard allocation policy does not exist as of this writing. However, an example configuration is provided in [13]. The AF/EF queues would be serviced using a WFQ or Stochastic Fair Queuing (SFQ) implementation. The WFQ/SFQ scheduling scheme will provide equitable treatment to all traffic. Thus during normal operating conditions emergency packets will not be given unnecessarily good QoS. The efficacy of this technique comes into play when an emergency occurs and the router queues start building up. Talauliker & Beard Expires - December 2002 [Page 7] Internet-Draft IEPREP in a Diffserv Domain June 2002 Depending on the variant of RED used (i.e., WRED, RIO-C, RIO-DC or GRIO-C), the router would start dropping packets, starting with the packets with highest drop precedence (i.e., red color packets). RIO would thus be used to provide preferential treatment to priority traffic by discarding packets of normal flows in the event of congestion. This would either cause the normal flows to slow down (if TCP responsive) or will cause non-responsive flows [7] to be discarded to remove their impact on priority traffic. To summarize, WFQ/SFQ provides QoS to all traffic, MRED provides preferential treatment to emergency traffic. The issues of allocating flows with appropriate AF/EF codepoints, choosing a specific MRED algorithm for queue management and deciding upon RIO drop thresholds are subjects of research. 8. Security Considerations This document does not raise any security concerns about using the AF PHB for emergency traffic. References [1] http://conrel.sice.umkc.edu/ieprep. [2] H. Folts, C. Beard, "Requirements for Emergency Telecommunication Capabilities in the Internet," Work-in- Progress, draft-ietf-ieprep-requirements-00.txt, June 19, 2002. [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, ôAn Architecture for Differentiated Servicesö, RFC 2475, December 1998. [4] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, ôAssured Forwarding PHB Groupö, RFC 2597, June 1999. [5] V. Jacobson, K. Nichols, K. Poduri, ôAn Expedited Forwarding PHBö, RFC 2598, June 1999. [6] S. Floyd, V. Jacobson, ôRandom Early Detection gateways for Congestion Avoidanceö, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, pp 397-413. [7] B. Braden, et al., ôRecommendations on Queue Management and Congestion Avoidance in the Internetö, RFC 2309, April 1998. Talauliker & Beard Expires - December 2002 [Page 8] Internet-Draft IEPREP in a Diffserv Domain June 2002 [8] J. Babiarz, ôEmpirical Study of Buffer Management Scheme for Diffserv Assured Forwarding PHBö, Proceedings Ninth International Conference on Computer Communications and Networks, Las Vegas, Nevada, October 2000. [9] M. Goyal, A. Durressi, R. Jain, C. Liu, P. Misra, ôEffect of Number of Drop Precedences in Assured Forwardingö, GLOBECOM 99, Rio De Janeiro, December 1999. [10] D. Clark, W. Fang, ôExplicit Allocation of Best Effort Packet Delivery Serviceö, ACM Transactions on Networking, Vol. 6, No 4, August 1998, pp 362-373. [11] O. Elloumi, D. Snodder, K. Pauwels, ôUsefulness of three drop precedence in Assured Forwarding serviceö, draft-elloumi- diffserv-threevstwo-00.txt, (work in progress), July 1999. [12] N. Seddigh, B. Nandy, P. Pieda, ôBandwidth Assurance issues for TCP flows in a Differentiated Services Networkö Proceedings of Global Internet Symposium, GLOBECOM 99, Rio De Janeiro, December 1999. [13] F. Baker, ôIEPS Requirements Statementö, draft-baker-ieps- requirements-00.txt, (work in progress), November 2001. Author's Addresses Salil Talauliker School of Interdisciplinary Computing and Engineering University of Missouri-Kansas City 5100 Rockhill Road Kansas City, MO 64110 Phone: 1-816-665-2626 Email: sut0b6@umkc.edu Cory Beard School of Interdisciplinary Computing and Engineering University of Missouri-Kansas City 5100 Rockhill Road Kansas City, MO 64110 Phone: 1-816-235-1550 Email: beardc@umkc.edu Talauliker & Beard Expires - December 2002 [Page 9]