Transport Working Group J. Gunn Internet-Draft Computer Sciences Corporation Intended status: Informational R. Lichtenfels Expires: August 23, 2007 National Communications System D. Garbin D. Masi Noblis P. McGregor Nyquetek February 23, 2007 Performance Evaluation of EF-ADMIT draft-gunn-tsvwg-ef-admit-evaluation-00 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 August 23, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A new Differentiated Services Code Point (DSCP), EF-ADMIT, has been recommended for a class of real-time traffic conforming to the Expedited Forwarding (EF) Per Hop Behavior (PHB) and admitted using a strong Call Admission Control (CAC) procedure incorporating capacity assurance, as compared to a class of real-time traffic conforming to the EF PHB but not subject to strong CAC. This document presents modeling results demonstrating that EF-ADMIT traffic will experience Gunn, et al. Expires August 23, 2007 [Page 1] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 low packet drop rates even when lack of strong CAC results in EF traffic experiencing high packet drop rates. The modeling shows the performance benefit is material at low to medium network access speeds (e.g., 256 Kb/s to 1.5 Mb/s), but relatively inconsequential at high access speeds (e.g., 45 Mb/s) and, by inference, backbone speeds (100Mb/s and higher) where more bandwidth headroom is assumed. Furthermore, mixing relatively long packets (e.g., 1500 byte video packets) with relatively short packets (e.g., 200 byte voice packets) in EF PHB causes significant degradation to short packet performance at low to medium access speeds. Finally, the results show that implementation can be effective utilizing either one queue with combined EF and EF-ADMIT flows, or two queues with one forEF-ADMIT flows and one for EF flows, with the choice of approach mostly a matter of policy. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 4 4. Models Description . . . . . . . . . . . . . . . . . . . . . . 6 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. High Speed Access (45 Mb/s) Simulation Results . . . . . . . 9 7. Medium Speed Access (1.5 Mb/s) Simulation Results . . . . . . 11 8. Low Speed Access (256 Kb/s) Simulation Results . . . . . . . . 13 9. Analytic Validation of Simulation Results . . . . . . . . . . 14 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 15.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 1. Introduction A recommendation has been made to request a new DSCP, EF-ADMIT, for a class of real-time traffic conforming to the EF PHB [RFC3246] [RFC3247] and admitted using a CAC procedure involving authentication, authorization, and capacity admission, as compared to a class of real-time traffic conforming to the EF PHB but not subject to CAC or subject to very weak CAC [Bake 06]. This document reports results of modeling the expected benefits to be achieved. As practitioners in providing essential network services for disaster response, the authors and contributors conclude that the use of EF-ADMIT to mark packets associated with disaster response VoIP traffic that is subject to strict CAC can be significant to our success. Gunn, et al. Expires August 23, 2007 [Page 2] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 Various means may be expected to generally restrict session admission to ensure that admitted traffic receives acceptable service. Most admission processes can achieve acceptable results relying on statistical load and capacity characterizations coupled with reasonably conservative engineering practices. These admission processes generally do not require specific capacity assurance for admission and are vulnerable to events that may cause statistical aberrations. In particular, existing VoIP services that perform no capacity admission or only very coarse capacity admission can exceed their allocated resources. Although such aberrations may cause significant degradation in service, their rarity coupled with the economic cost to prevent them may make them acceptable for most users and service providers. However, some services, such as those supporting response to natural and manmade disasters, including acts of terror, must minimize vulnerability to such degradation. Disasters can cause extraordinary service demand by the public while concurrently causing outages that reduce network capacity to serve the surging demand. During such events it is imperative that services supporting disaster response continue to perform with minimal degradation. General requirements, and IP telephony specific requirements, for such Emergency Telecommunications Service are discussed in [RFC3689] and [RFC3690]. In this regard, it should be noted that disaster response services are not the (perhaps) more familiar emergency services (such as E911 in the United States). Disaster response services are essential for leadership and key staff to coordinate resources to deal with a disaster. Emergency services generally support the public's access to first responders. Disaster response services are expected to have relatively small demand compared to the public demand, and can be economically subjected to strong CAC. However, it is most important that once a service request is admitted that it be successfully served. The EF-ADMIT DSCP with appropriate corresponding PHB would provide this assurance in all circumstances. The authors and contributors are particularly concerned with ensuring that essential network services for disaster response are assured under all circumstances. 9We have applied both event simulation and analytical models to evaluate the potential benefit of an EF-ADMIT DSCP. As discussed in this document, we believe the results demonstrate significant value in preserving EF-ADMIT performance even when significant aberration in demand and / or capacity causes EF performance to significantly degrade. 2. Definitions The following terms and acronyms are adopted, unchanged, from [Bake 06]. PHB: A Per-Hop-Behavior (PHB) is the externally observable Gunn, et al. Expires August 23, 2007 [Page 3] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 forwarding behavior applied at a DS-compliant node to a DS behavior aggregate [RFC2475]. It may be thought of as a program configured on the interface of an Internet host or router, specified drop probabilities, queuing priorities or rates, and other handling characteristics for the traffic class. DSCP: The Differentiated Services Codepoint (DSCP), as defined in [RFC2474], is a value which is encoded in the DS field, and which each DS Node must use to select the PHB which is to be experienced by each packet it forwards [RFC3260]. It is a 6-bit number embedded into the 8-bit TOS field of an IPv4 datagram or the Traffic Class field of an IPv6 datagram. CAC: Call Admission Control, which includes concepts of authorization (an identified and authenticated user is determined to also be authorized to use the service) and capacity admission (at the present time, under some stated policy, capacity exists to support the call). In the Internet, these are separate functions, while in the PSTN they and call routing are carried out together. The following terms and acronyms are intended to be intuitive simplifications of the precise definitions and descriptions given in the cited references. EF: Expedited Forwarding is a DSCP to mark packets for processing through a PHB designed to ensure low delay and jitter. The EF PHB is generally thought to be implemented by some form of priority queue. A precise definition of EF is given in [RFC3246]. AF: Assured Forwarding is a range of DSCPs from AF11 to AF43 to mark packets for processing through corresponding PHBs designed to achieve minimal packet loss although accepting of greater delay and jitter than EF. For illustration, AF1 may be envisioned to be appropriate for video and AF2 for signaling. A precise definition of AF is given in [RFC2597]. BE: Best Effort is a DSCP to mark packets for processing through a corresponding PHB for which there is no committed performance objectives (although there may be a committed capacity) for the design. A description of BE as the default treatment in differentiated services is given in [RFC2474]. 3. Problem Description The problem is to evaluate the performance benefit of using an EF- ADMIT DSCP in addition to the EF DSCP. Both EF and EF-ADMIT are used for the same class of service, differing only in their CAC strength. Of particular interest is the service being bearer voice service, i.e., the actual packet stream forming the voice media. Voice service is the primary communications service used to coordinate Gunn, et al. Expires August 23, 2007 [Page 4] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 disaster response today. Also of interest is the implication of extending the service to include both voice bearer and video bearer. This extension is of interest in that it may offer a way to serve the emerging needs of disaster response for assured video by using the same logical resources as contemplated for voice. The general problem structure incorporates the following assumptions: a) A physical communications link is engineered to support a mix of EF voice packets, AF1 video packets, AF2 assured data packets and BE data packets, each achieving expected performance metrics when demand is at the level for which they were engineered. This level of demand is referred to as "1X Load". b) Disaster conditions cause the demand for service to greatly exceed the engineered level, perhaps by as much a factor of five, i.e., a "5X Overload". (In the public switched telephone network experience, disasters have been documented to produce demand of up to 10X Overload.) Note that "Overload" is normalized to engineered "Load", and not to link capacity. c) Disaster response traffic can be up to 10% of the 1X Load (i.e., up to 2% of the 5X Overload). Experience to date with selected disaster response services suggests an actual disaster response network-wide load of much less than .1% of the 1X load even during a 10X overload event. On any particular interface, concentrations of activity may cause the load to be significantly higher than on a network-wide basis, but it is still expected to be much less than 1%. However, as service awareness and user authorizations grow, 1% is considered to be a reasonable maximum, and 10% is viewed as very conservative for engineering. To evaluate the benefit of EF-ADMIT, the following questions are addressed: 1) If EF is the only DSCP for VoIP and EF demand is not effectively controlled by CAC, what will be the performance of EF? 2) If EF-ADMIT is introduced for VoIP traffic subjected to strong CAC, and EF demand is not effectively controlled by CAC, what will be the performance of (EF and) EF-ADMIT? 3) What is the performance of the other traffic? 4) What happens to the EF-ADMIT performance if video is added? Within this general structure, two approaches are considered for how Gunn, et al. Expires August 23, 2007 [Page 5] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 the EF and EF-ADMIT PHBs might be implemented: (1) one queue shared by the two DSCPs (referred to as 2EF/1Q), but with each DSCP still having its own input policing, and (2) a separate queue for each DSCP (referred to as 2EF/2Q), each with its own input policing. The difference in concept is shown in Figure 1. Police EF --------> <=> -------\ \ ----------| -----> | | |------> / ----------| EF-ADMIT ---> <=> -------/ Police Police -------------| EF --------> <=> -------> | | | --------> -------------| -------------| EF-ADMIT ---> <=> -------> | | | --------> Police -------------| Figure 1: One Queue and Two Queues Approaches In both approaches, the AF1, AF2, and BE PHBs are served via a Class Based Weighted Fair Queuing (CBWFQ) scheduler. In the 2EF/1Q approach, the combined EF / EF-ADMIT queue has higher priority than all the CBWFQ queues. In the 2EF/2Q approach, the EF-ADMIT queue has the highest priority, followed by the EF queue, and then the CBWFQ queues. However, it should be noted that policing of 2EF/1Q and 2EF/2Q can ensure they do not starve the CBWFQ queues. In such an approach, because the EF queue does not have strong CAC, its packet arrival rate during 5X Overload can exceed its allocated capacity and the policing results in a high rate of packet dropping. However, the EF-ADMIT queue does have strong CAC, so its packet arrival rate is always below its allocated capacity and it does not suffer a high packet loss rate. Calls could be blocked by the CAC, but the calls that are admitted should be assured of meeting their performance objectives. 4. Models Description The event simulation model is implemented in OPNET Modeler. A Cisco access-class router is chosen as the queuing platform. This router provides all the functionality needed to implement priority queuing, with and without input policing, and CBWFQ. In the model, EF demand is not subject to CAC, and the degree of policing varies from none to Gunn, et al. Expires August 23, 2007 [Page 6] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 1X, where results labeled as "Policed 1X" means the 5X Overload arriving EF packets are policed down to the normal load (i.e., 1X) before presentation to the queue. A "Policed 2X" label means the arriving 5X Overload is policed down to twice the normal load (i.e., 2X). The policing is implemented as single rate, burst control policing. Packet loss rates are expressed relative to the pre- policed load, i.e., relative to the 5X Overload versus the Policed 2X Overload. The AF1, AF2, and BE flows through the CBWFQ are not subjected to policing, but do suffer packet loss from tail dropping. In all cases, the network control traffic is not explicitly modeled, but is assumed to be otherwise protected. The "No Policing of EF" cases (not consistent with [RFC3246]) are intended to explore the boundary conditions, rather than representing realistic networks. The router model does not support implementing two priority queues (e.g., EF and EF-ADMIT) as well as CBWFQ. To overcome this obstacle, in the simulation model two routers are chained together. The first router provides CBWFQ for the AF1, AF2, and BE traffic. The second router is configured with two (or three) priority queues. The highest priority queue (or highest and second highest queues) serves the combined EF traffic and EF-ADMIT traffic (or the separate EF and EF-ADMIT traffic). The output of the CBWFQ router is connected as the input to the lowest priority queue of the first router. The capacity of the interconnecting link is the same as the output of the first router reduced by the steady-state bandwidth occupied by the EF (and EF-ADMIT) traffic. The interconnecting link capacity reduction mimics the behavior of CBWFQ configurations with Low-Latency Queuing features which remove the bandwidth consumed by the low-latency queues from the class-based queue allocations. The arrangement is shown in Figure 2 for EF-ADMIT and EF merged into one queue, and in Figure 3 for EF-ADMIT and EF separated into two queues. The figures are essentially the same as given in [Bake 06]. policers priorities . EF-ADMIT ---> <=> -------\ |`. --||----+ `. EF2 -------> <=> -------/ high| `. . | Rtr .'-------- rate queues |`. +-----+ .' AF1------>||----+ `. / low | .' Priority | `. / |' Scheduler AF2------>||----+ Rtr.'-+ | .' CS0------>||----+ .' CBWFQ |' Scheduler Figure 2: Model Structure for Merged Flows Gunn, et al. Expires August 23, 2007 [Page 7] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 policers priorities |`. EF ---------> <=> ----------||----+ `. high| `. EF2---------> <=> ----------||----+ .'----------- . medium .' rate queues |`. +-----+ .' Priority AF1------>||----+ `. / low |' Scheduler | `. / AF2------>||----+ .'-+ | .' CS0------>||----+ .' Rate Scheduler |' (WFQ, WRR, etc) Figure 3: Model Structure for Separate Flows The analytical model is organized around the same concept. A priority queue model is integrated with a CBWFQ model. The priority queue model is discussed in [Cohe 69]. Both the priority model and the CBWFQ model assume that the packet arrival processes are independent Poisson processes. The packet sizes (and thus transmission times) are assumed by the priority queue model and the CBWFQ model to be independent random variables; we use the distributions shown in Table 1. WhenEF-ADMIT and EF are merged into a single queue, the merged process is given the highest priority in the priority queue model. When the EF-ADMIT and EF flows are in separate queues, the EF-ADMIT queue is given the highest priority, while the EF queue is given the second highest priority. In either case, delay and packet loss for EF-ADMIT and EF flows are estimated from the priority queue model (adjusted to account for finite buffers). A technique called the Transform Recursion Method(TRM) is used to estimate the cumulative distribution function, and thus the jitter, of the delay (see [Fisc 07]). The CBWFQ model assumes that the residual bandwidth after the EF-ADMIT and EF flows are served is available for the data classes. The bandwidth is allocated to the data classes initially based on the CBWFQ weights that are assigned to each data class. An iterative procedure is used to re-allocate the bandwidth from data classes that are not utilizing their allocated bandwidth to those classes that are overloading their allocated bandwidth. Upon convergence of this iterative algorithm, final estimates of delay, jitter, and packet loss are obtained for the data classes. The resulting probability that a data packet is in service when a higher priority EF-ADMIT or EF packet arrives is used to adjust the EF-ADMIT and EF measures to account for any residual data class transmission time that is occurring. For a discussion on analytical models on priority queuing and CBWFQ, see [Harr 00], [Fisc 07] and references therein. Five traffic flows are modeled with the attributes shown in Table 1. Packets are modeled as having Poisson arrivals with packets of the specified sizes. Gunn, et al. Expires August 23, 2007 [Page 8] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 Traffic Type * Per Call * Packet * Mean * Pkt * Prcent * Packet * Size * * Size * * Generation * Distrbtn * Bytes * Bytes * * Rate * * * * ****************************************************************** EF-ADMIT Voice * 50 pps * Constant * 200 * * ****************************************************************** EF Voice * 50 pps * Constant * 200 * * ****************************************************************** AF1 Video * 40 pps * Discrete * 1,365 * 900 * 15% * * X3 * * 1,200 * 15% * * * * 1,500 * 70% ****************************************************************** AF2 Data * * Discrete * 695 * 40 * 50% * * X3 * * 750 * 10% * * * * 1,500 * 40% ****************************************************************** BE Data * * Discrete * 695 * 40 * 50% * * X3 * * 750 * 10% * * * * 1,500 * 40% Table 1: Traffic Attributes Used in Modeling A discussion of different service classes and corresponding practices to achieve desired performance is given in [RFC4594]. Guidelines for the aggregation of different service classes into forwarding treatments are provided in [Chan 06]. Three line speeds are modeled: a) Low Speed Access at approximately 256 Kb/s (a low DSL speed) b) Medium Speed Access at approximately 1.5 Mb/s (T1) c) High Speed Access at approximately 45 Mb/s (T3) The first two of these speeds are viewed as popular premise-to- network access speeds, and the third as the high end of access speeds and the low end of backbone speeds. Within the United States, demographic data indicates about 40% of "broadband" internet access lines (i.e., access arrangements other than for modems) have speeds of less than 2.5Mb/s [FCC 06]. Our experience with a particular large Federal Agency indicates that 75% of its locations have access speeds of T1 or less. The key performance metrics are delay, jitter, and packet loss. As a point of reference, our engineering allocation to the access segment at one end of a call suggests the following values based on [ITU 06] to ensure a reasonable user experience: Delay: Less than 50 ms Gunn, et al. Expires August 23, 2007 [Page 9] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 Jitter: Less than 30 ms Packet Loss: Less than .1% 5. Scenarios The Baseline scenario hypothesizes what is felt to be a reasonable loading for each of the traffic flows during normal "busy-hour" conditions for each of the access speeds. It is not based on actual VoIP measurementsIn the Baseline there is no EF-ADMIT voice load as the interest is in use of the EF-ADMIT to provide performance assurance to disaster response traffic during significant overload conditions. The Baseline scenario is shown as Table 2, and produced utilizations of about 80% for the lower speeds, and about 50% for the higher speed. The difference in utilization is consistent with our practical experience. The Baseline loading is referred to as "1X" load. Traffic Type * Low Speed Acc * Med Speed Acc * High Speed Acc * 256 Kb/s * 1.5 Mb/s * 45 Mb/s * Calls Mb/s * Calls Mb/s * Calls Mb/s ****************************************************************** EF-ADMIT Voice * 0 0.00 * 0 0.00 * 0 0.00 EF Voice * 1 0.08 * 5 0.40 * 100 8.00 AF1 Video * 0 0.00 * 1 0.44 * 20 8.76 AF2 Prity Data * 0.03 * 0.08 * 1.68 BE Data * 0.08 * 0.25 * 5.04 ****************************************************************** Utilization * 78.6% * 80.2% * 55.7% Table 2: Baseline 1X Load After modeling the Baseline scenario, different overload scenarios are introduced. In each scenario the overall load is approximately five times the Baseline, i.e. "5X" overload. As noted earlier, this level of overload is in the range of historical circuit switched disaster demands. The EF-ADMIT traffic is nominally as much as 1% of the Baseline EF traffic (based on disaster response traffic experience in the US), but, to be conservative, it is modeled at about 10%, or at least one call, whichever is greater. The scenarios are: a) 2EF/1Q - No Police: Configured to merge the EF and the EF-ADMIT traffic into one queue, with the EF-ADMIT traffic having strong capacity admission control and the EF traffic having neither significant capacity admission control, nor policing. b) 2EF/2Q - No Police: Configured to separate the EF and EF-ADMIT flows into two queues, with the EF-ADMIT having strong capacity admission control and the EF having neither capacity admission control nor any policing. Gunn, et al. Expires August 23, 2007 [Page 10] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 c) 2EF/1Q - Police 2X: Configured to separate the EF and EF-ADMIT flows into two queues, with the EF-ADMIT having strong capacity admission control and the EF having no capacity admission control, but with policing applied to limit the rate of EF marked packets presented to the queue to only two times the rate for which it is normally configured. This scenario illustrates the use of EF policing (consistent with [RFC3246]), even if there is no strong EF capacity admission control, to ensure that essential traffic gets the necessary performance. The implication of using EF-ADMIT to not only ensure voice performance, but also video performance is examined for the medium (1.5 Mb/s) and high (45 Mb/s) access speeds. It is not examined for the low (256 Kb/s) speed simply because the low speed is not fast enough to support the assumed video rate. The results of the modeling are presented and discussed in the next three sections, each section addressing one of the three speeds. 6. High Speed Access (45 Mb/s) Simulation Results With access speeds at 45 Mb/s or higher (i.e., T3 speeds and above) there is little need to for separate EF and EF-ADMIT marking and treatment to ensure meeting delay and jitter performance objectives; however, if EF does not have effective CAC and is not policed, then the load can be made large enough to overrun the link capacity and cause packet loss that will be out of tolerance. In this case, if there is no differentiation in treatment between EF and EF-ADMIT, the packet loss rate will apply to both EF and EF-ADMIT and both will have unacceptable performance. As long as the combined EF and EF- ADMIT load remains somewhat below the link capacity, then even if EF-ADMIT is used to add a limited number of video sessions to the limited number of voice sessions, the metrics for EF-ADMIT voice remain reasonable. Results for the combined load less than link capacity with no EF CAC or policing are given in Table 3. Voice delay and jitter at 1X load are essentially negligible, and there are no packets dropped for voice or for any of the other services. At 5X overload, there are still no packets dropped for either EF or EF-ADMIT, mostly because the 1X load for EF is less than 1/5 of the link capacity and there is no EF CAC or policing to prevent the EF priority from starving the CBWFQ services. The 5X Overload causes EF to essentially consume all the link capacity and provides the expected view of performance in terms of delay and jitter, as described in [Bake 06]. The one queue case shows the same delay (.8 ms) and jitter (4.9 ms) for EF and EF-ADMIT, whereas the two queue case shows significantly smaller delay (0.0 ms) and jitter (.3 ms) for EF-ADMIT than EF (.8 ms and 5.0 ms). However, in both cases, the delay and jitter for EF is well within tolerance for high qualityconversation and the introduction of EF-ADMIT has a minimal impact on EF performance. Gunn, et al. Expires August 23, 2007 [Page 11] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 The priority treatment of voice (EF and EF-ADMIT) has a very significant impact on the performance of the other services (AF1 video, AF2 priority data, and BE data). As noted above, the voice overload uses almost all the capacity, so the other services suffer packet drop rates in excess of 90%. The overall result for high speed access is that voice, if given priority, will perform very well with or without EF-ADMIT, although significant overload will cause it to materially impair the performance of other services. The modeling results also show that in the single queue case the introduction of a small amount of video into the merged EF and EF- ADMIT flow does increase delay (from 0.8 ms to 1.2 ms) and jitter (from 4.9 ms to 5.1 ms), but it is a very small increase. If EF and EF-ADMIT are separated into two queues, then the introduction of the video into EF-ADMIT has essentially no impact on the EF-ADMIT performance, but it does have a detectable impact on the EF performance, increasing delay from .8 ms to 3.3 ms and increasing jitter from 5.0 ms to 10.2 ms. These results are still well within tolerance for high quality conversation, and there remain no dropped packets. As before, the other services suffer high packet drop rates, greater than 90%, as the priority voice consumes the available capacity. With high speed access, the addition of a small amount of video to EF-ADMIT does not materially reduce the high quality of voice performance. 7. Medium Speed Access (1.5 Mb/s) Simulation Results With access speeds at 1.5 Mb/s, it is effective to either ensure effective policing of EF traffic for the one queue case, or to adopt the two queue approach. The addition of a limited amount of video to the EF-ADMIT flow in both cases degrades EF-ADMIT performance to marginal, and, in the case of a separate queue for EF-ADMIT, reduces EF performance to unacceptable. The results are given in Table 4. As may be expected, voice delay and jitter at 1X load are well within tolerance for high quality conversation, and there are no packets dropped for voice or for any of the other services. At 5X overload, the one queue case without any EF policing essentially overruns the link capacity and 30% of the EF and EF-ADMIT packets are dropped as well as all the packets for the other services. The voice packet delay has grown significantly compared to the 1X Baseline, from 2.9 ms to 9.5 ms, but the jitter has grown only a little, from 9.8 ms to 11.0 ms. Both delay and jitter remain within tolerance, but the packet drop rate is certainly unacceptable. By applying policing to limit EF traffic (to no more than 2X the engineered load in the model), EF-ADMIT in the one queue case can have its packet loss rate reduced to an acceptable level (.2% in the Gunn, et al. Expires August 23, 2007 [Page 12] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 High Speed Access * 1X Load * 5X Overload (45 Mb/s) * * ******************************************************************** Case / Flow * Baseline * EF-ADMIT * EF-ADMIT * * Voice Only * Voice and Video * * EF/1Q 2EF/2Q * 2EF/1Q 2EF/2Q * * No No * No No * * Police Police * Police Police ******************************************************************** EF-ADMIT * * * Voice * * * Calls * 0 * 10 10 * 10 10 Mb/s * 0 * 0.80 0.80 * 0.80 0.80 Video * * * Calls * 0 * * 2 2 Mb/s * 0 * * 0.87 0.87 Delay (ms) * N/A * 0.8 0.0 * 1.2 0.0 Jitter (ms) * N/A * 4.9 0.3 * 5.1 0.3 Packet Loss * N/A * 0.0% 0.0% * 0.0% 0.0% ********************************************************************* EF-Voice * * * Calls * 100 * 500 500 * 500 500 Mb/s * 8.00 * 40.00 40.00 * 40.00 40.00 Delay (ms) * 0.1 * 0.8 0.8 * 1.2 3.3 Jitter (ms) * 0.3 * 4.9 5.0 * 5.1 10.2 Packet Loss * 0.0% * 0.0% 0.0% * 0.0% 0.0% ******************************************************************** AF1 Video * * * Sessions * 20 * 100 100 * 98 100 Mb/s * 8.76 * 43.68 43.68 * 43.68 43.68 Packet Loss * 0.0% * 99.0% 99.0% * 99.5% 99.5% ******************************************************************** AF2 Priority Data* * * Mb/s * 1.68 * 8.34 8.34 * 8.34 8.34 Packet Loss * 0.0% * 93.2% 93.2% * 98.2% 98.2% ******************************************************************** BE Data * * * Mb/s * 5.04 * 25.02 25.02 * 25.02 25.02 Packet Loss * 0.0% * 99.3% 99.3% * 99.8% 99.8% ******************************************************************** Utilization * 56% * 267% 267% * 267% 267% Table 3: Model Results for High Speed Access Gunn, et al. Expires August 23, 2007 [Page 13] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 Med Speed Access * 1X Ld * 5X Overload (1.5 Mb/s) * * ********************************************************************* Case / Flow *Baseline* EF-ADMIT * EF-ADMIT * * Voice Only * Voice and Video * * 2EF/1Q 2EF/1Q 2EF/2Q * 2EF/1Q 2EF/2Q * * No 2X No * 1X No * * Police Police Police * Police Police ********************************************************************* EF-ADMIT * * * Voice * * * Calls * 0 * 1 1 1 * 1 1 Mb/s * 0 * 0.08 0.08 0.08 * 0.08 0.08 Video * * * Calls * 0 * * 1 1 Mb/s * 0 * * 0.44 0.44 Delay (ms) * N/A * 9.5 4.6 0.6 * 6.8 2.3 Jitter (ms) * N/A * 11.0 11.7 2.1 * 31.6 25.6 Packet Loss * N/A * 30.0% 0.2% 0.0% * 0.1% 0.0% ********************************************************************* EF-Voice * * * Calls * 5 * 25 10 25 * 5 25 Mb/s * 0.40 * 2.00 0.80 2.00 * 0.40 2.00 Delay (ms) * 2.9 * 9.5 4.6 10.1 * 6.8 15.5 Jitter (ms) * 9.8 * 11.0 11.7 15.3 * 31.6 86.7 Packet Loss * 0.0% * 30.0% 60.0% 31.0% * 80.0% 53.0% ********************************************************************* AF1 Video * * * Sessions * 1 * 5 5 5 * 4 4 Mb/s * 0.44 * 2.18 2.18 2.18 * 1.75 1.75 Packet Loss * 0.0% * 100.0% 88.8% 100.0% * 87.5% 53.0% ********************************************************************* AF2 Prity Data * * * Mb/s * 0.08 * 0.42 0.42 0.42 * 0.42 0.42 Packet Loss * 0.0% * 100.0% 36.9% 100.0% * 40.5% 100.0% ********************************************************************* BE Data * * * Mb/s * 0.25 * 1.25 1.25 1.25 * 1.25 1.25 Packet Loss * 0.0% * 100.0% 91.7% 100.0% * 93.7% 100.0% ********************************************************************* Utilization * 80% * 386% 308% 386% * 308% 308% Table 4: Medium Speed Access (1.5 Mb/s) Simulation Modeling Results model). The delay (4.6 ms) and jitter (11.7 ms) for EF and EF-ADMIT remain acceptable. Although EF delay and jitter are acceptable, EF packet policing causes significant packet loss and EF quality will not be acceptable. With EF policing, there is some freeing of capacity for other services, and although their drop rates are still Gunn, et al. Expires August 23, 2007 [Page 14] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 very high, at least some packets are getting through. If EF and EF-ADMIT are provided separate queues, then EF-ADMIT performance stays very good even if there is no policing applied to EF. Delay is low (.6 ms), jitter is low (2.1 ms) and there are no packets dropped. However, there is an offsetting transfer of delay and jitter to EF compared to the one queue case, raising delay from 9.5 ms to 10.1 ms and raising jitter from 11.0 ms to 15.3 ms. There is also a small increase in packets dropped, from 30% to 31%. These results suggest that both the one queue approach with at least some degree of EF policing and the two queue approach can be effectively configured to ensure EF-ADMIT performance during severe congestion. The modeling results also show that in both the single queue and two queue approaches, the introduction of a small amount of video into the EF-ADMIT flow does make performance for both EF and EF-ADMIT at best marginal. In the one queue case with EF policing, it increases delay from 4.6 ms to 6.8 ms, and jitter from 11.7 ms to 31.6 ms. The increase in jitter makes the performance marginal for high quality voice conversation. If EF and EF-ADMIT are separated into two queues, then the introduction of the video into EF-ADMIT increases delay from .6 ms to 2.3 ms, still very good, but increases jitter from 2.1 ms to 25.6 ms, making performance marginal. The impact on EF is more severe, with delay increasing from 10.1 ms to 15.5 ms, and jitter increasing from 11.7 ms to 86.7 ms, clearly unacceptable. As before, the other services suffer high packet drop rates. With one queue and EF policing set to ensure at least some capacity available for other services, the drop rates are greater than 40%, but with two queues and no EF policing, the voice (EF and EF-ADMIT) consumes the available capacity and all other service packets are dropped. With medium speed access, the addition of a small amount of video to EF-ADMIT does materially reduce voice performance. 8. Low Speed Access (256 Kb/s) Simulation Results With access speeds at 256 Kb/s, at 1X load there is no capacity for video, and integration of voice and data causes unacceptable voice jitter. Assuming data packet segmentation can be used to address the jitter issue, then it becomes very important to either ensure effective policing of EF traffic for the one queue case, or to adopt the two queue approach. The results of the simulation modeling are given in Table 5. Voice delay (17.1 ms) at 1X is within tolerance, but jitter (59.8 ms) requires data packet segmentation to be made acceptable. As expected, there are no packets lost for any of the services. At 5X load with one queue and no EF policing (i.e., essentially the baseline configuration during congestion) delay (61.6 ms) is greatly increased to become unacceptable, and jitter (65.8 ms) remains unacceptable with a slight increase. The 5X overload overwhelms the link capacity Gunn, et al. Expires August 23, 2007 [Page 15] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 Low Speed Access * 1X Ld * 5X Overload (256 Kb/s) * * ********************************************************** Case / Flow * Baseline * EF-ADMIT * * * Voice Only * * * 2EF/1Q 2EF/1Q 2EF/2Q * * * No 2X No * * * Police Police Police * *********************************************************** EF-ADMIT * * * Calls * 0 * 1 1 1 * Mb/s * 0 * 0.08 0.08 0.08 * Delay (ms) * N/A * 61.6 30.1 4.9 * Jitter (ms) * N/A * 65.8 65.7 25.1 * Packet Loss * N/A * 49.0% 4.0% 0.0% * *********************************************************** EF-Voice * * * Calls * 1 * 4 2 4 * Mb/s * 0.08 * 0.32 0.16 0.32 * Delay (ms) * 17.1 * 61.6 30.1 93.0 * Jitter (ms) * 59.8 * 65.8 65.7 195.1 * Packet Loss * 0.0% * 49.0% 54.0% 59.0% * *********************************************************** AF1 Video * * * Sessions * 0 * 0 0 0 * Mb/s * 0.00 * 0.00 0.00 0.00 * Packet Loss * N/A * N/A N/A N/A * *********************************************************** AF2 Prity Data * * * Mb/s * 0.03 * 0.14 0.14 0.14 * Packet Loss * 0.0% * 100.0% 100.0% 100.0% * *********************************************************** BE Data * * * Mb/s * 0.08 * 0.33 0.33 0.33 * Packet Loss * 0.0% * 100.0% 100.0% 100.0% * *********************************************************** Utilization * 79% * 393% 277% 493% * Table 5: Low Speed Access (256 Kb/s) Simulation Results link capacity causing 49% of the voice packets to be dropped and all the packets are dropped for the other services. As before, by policing the EF traffic to be not more than 2X the engineered load, the EF-ADMIT packet drop rate (4%) can be made (almost) acceptable. The EF packet drop rate remains high and unacceptable due to the policing. For both EF and EF-ADMIT, delay (30.0 ms) can be made nearly tolerable. The jitter (65.7 ms) remains unacceptable, but presumably can be fixed with data packet segmentation. The results suggest that with sufficient attention to configuring, particularly to ensure maximum packet lengths and policing of EF traffic, the one queue approach can be made acceptable. Gunn, et al. Expires August 23, 2007 [Page 16] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 The two queue approach permits EF-ADMIT traffic to be served within tolerance even though the 5X overload causes dropping of all packets for data services, and causes EF performance to be clearly unacceptable. EF-ADMIT delay (4.9 ms) is well within tolerance and jitter (25.1 ms) is within tolerance, although perhaps marginal. There are no EF-ADMIT packets dropped. This EF-ADMIT performance is achieved even though there is 5X overload, no EF policing, and no data packet segmentation. This suggests the two queue approach is very robust for EF-ADMIT. However, note that EF delay has increased to 93.0 ms, and EF jitter has increased to 195.1 ms, and packet drop rate is at 59%, all unacceptable. The results suggest that the two queue approach is very robust for EF-ADMIT, but still requires attention to managing EF as well as data packet segmentation if any EF voice overload is to be served concurrently. 9. Analytical Validation of Simulation Results Analytical modeling has independently been applied and corroborates the simulation results, showing very close agreement. As noted in Section 4, the analytical model is based on integrating priority queuing and an iterative queuing algorithm to model the CBWFQ queuing of the second router and its interconnection to the priority queuing of the first router. Results for Low Speed Access (256 Kb/s) comparing the event simulation using OPNET results with the analytic model results for 1X load and for overloading data by 5X (but not voice) are given in Table 6. The greatest difference seems to be at 5X overload where the event simulation model shows .004% packet drop rate and the analytic model shows a .012% drop rate. Although proportionately the difference is large, both numbers are very small and probably acceptable as being within reason for modeling results. The close agreement of the simulation and analytical models tends to validate each. 10. Conclusion [Bake 06]recommends a new DSCP, EF-ADMIT. This document reports event simulation and analytical modeling results portraying the benefit of an EF-ADMIT DSCP. The authors and contributors of this document are particularly concerned with ensuring that disaster response service is assured under all circumstances. As discussed in the document, we believe the results demonstrate significant value in preserving EF-ADMIT performance even when significant aberrations in demand and / or capacity causes EF performance to significantly degrade. As practitioners in providing essential network services for disaster response, we conclude that EF-ADMIT can be significant to our success. Gunn, et al. Expires August 23, 2007 [Page 17] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 Low Speed Access * 1X Load * 5X Data Ovld, (256 Kb/s) * * No Voice Ovld * Baseline * EF / 1Q ********************************************************* Case / Flow * OPNET Analytics * OPNET Analytics ********************************************************* EF-ADMIT Voice * * * Calls * 0 0 * 0 0 * Mb/s * 0 0 * 0 0 * Delay (ms) * N/A N/A * N/A N/A * Jitter (ms) * N/A N/A * N/A N/A * Packet Loss * N/A N/A * N/A N/A * ********************************************************* EF-Voice * * * Calls * 1 1 * 1 1 * Mb/s * 0.08 0.08 * 0.08 0.08 * Delay (ms) * 17.1 17.0 * 24.3 24.3 * Jitter (ms) * 59.8 59.6 * 61.0 60.8 * Packet Loss * 0.0% 0.0% * 0.04% 0.012% * ********************************************************* AF1 Video * * * Sessions * 0 0 * 0 0 * Mb/s * 0.00 0.00 * 0.00 0.00 * Packet Loss * N/A N/A * N/A N/A * ********************************************************* AF2 Prity Data * * * Mb/s * 0.03 0.03 * 0.14 0.14 * Packet Loss * 0.0% 0.0% * 12.1% 11.8% * ********************************************************* BE Data * * * Mb/s * 0.08 0.08 * 0.33 0.33 * Packet Loss * 0.0% 0.0% * 90.0% 90.2% * ********************************************************* Utilization * 79% 79% * 216% 216% * Table 6: Event Simulation Results Compared to Analytic Results 11. Next Steps The evaluation of EF-ADMIT benefit is only one step in the process of evaluating concepts and strategies for ensuring network services for disaster recovery under all circumstances. Related steps that are anticipated in the near future are: a) Evaluating the implications of mixing voice signaling traffic with voice bearer traffic in the same PHBs. b) Since the results reported herein suggest disaster recovery video should not be mixed with disaster recovery voice in the same Gunn, et al. Expires August 23, 2007 [Page 18] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 PHB, determining how best to ensure video capabilities for disaster recovery under all circumstances. c) Assuming stricter policing (e.g. 50% of the link capacity as recommended in [RFC3247] of the EF traffic. d) Using 10X overload for the EF traffic (instead of 5X). e) Modeling other arrival rate and packet size distributions, for sensitivity f) Evaluating the vulnerability of, and assurance mechanisms for, disaster recovery data services, particularly in terms of how well the needs can be met by appropriate assignments within the framework of the existing AF classes. g) Corroborating the event simulation and analysis results with a prototype implementation of the model configuration in the laboratory and testing the performance for the various scenarios. 12. IANA Considerations IANA considerations are addressed in [Bake 06]; this document adds no new considerations. 13. Security Considerations Security considerations are addressed in [Bake 06]; this document adds no new considerations. 14. Contributors Richard Kaczmarek, Computer Sciences Corporation Marty Fischer, Noblis Jeff Xu, Booz Allen Hamilton Jay Vora, Booz Allen Hamilton 15. References 15.1 Normative References [Bake 06] Baker, F., Polk, J., and M. Dolly, "An EF DSCP for Capacity-Admitted Traffic", draft-ietf-tsvwg-admitted- realtime-dscp-00 (work in progress), December 2006. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. Gunn, et al. Expires August 23, 2007 [Page 19] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002. 15.2. Informative References [Chan 06] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", draft-ietf-tsvwg-diffserv- class-aggr-01 (work in progress), October 2006. [Cohe 69] Cohen, J. W., The Single Server Queue, North-Holland Publishing Company New York (1969). [FCC 06] "High-Speed Services for Internet Access: Status as of December 31, 2005", Industry Analysis and Technology Division, Wireline Competition Bureau, Federal Communications Commission, July 2006. [Fisc 07] Fischer, M.J. and D.M. Masi, " A Quantitative Analysis of the Voice and Data Quality of Service Problem", The Telecommunications Review 2007, Mitretek Systems, Falls Church, VA. [Harr 00] Harris, C.M., Brill, P.H., and M.J. Fischer, "Internet-Type Queues with Power-Tailed Interarrival Times and Computational Methods for Their Analysis," INFORMS Journal on Computing, Vol. 12, p. 261 - 271, 2000. [ITU 06] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services," 2006. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [RFC3689] Carlberg, K. and R. Atkinson, "General System Requirements for Emergency Telecommunications Service", RFC 3689, February 2004. Gunn, et al. Expires August 23, 2007 [Page 20] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service", RFC 3690, February 2004. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. Authors' Addresses Rick Lichtenfels National Communications System 701 South Court House Road Arlington, VA 22204 USA Phone: +1-703-607-6205 Email: Rick.Lichtenfels@disa.mil Janet Gunn Computer Sciences Corporation 15000 Conference Center Dr. Chantilly, VA 20151 USA Phone: +1-703-818-4725 Email: jgunn6@csc.com David Garbin Noblis 3150 Fairview Park Drive Falls Church, Virginia 22042 USA Phone: +1-703-610-2050 Email: david.garbin@noblis.org Denise Masi Noblis 3150 Fairview Park Drive Falls Church, Virginia 22042 USA Phone: +1-703-610-1582 Email: dmasi@noblis.org Patrick McGregor Nyquetek Inc Millersville, MD 21108 USA Phone: +1-410-729-0480 Email: pat_mcgregor@msn.com Gunn, et al. Expires August 23, 2007 [Page 21] Internet-Draft Performance Evaluation of EF-ADMIT February 2007 Full Copyright Statement Copyright (C) The IETF Trust (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, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gunn, et al. Expires August 23, 2007 [Page 22]