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]