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