Internet DRAFT - draft-gunn-tsvwg-ef-admit-evaluation
draft-gunn-tsvwg-ef-admit-evaluation
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]
