INTERNET-DRAFT R. Bless
Expires: August 2001 K. Wehrle
Universitaet Karlsruhe (TH)
Document: draft-bless-diffserv-le-phb-00.txt February 2001
A Limited Effort Per-Hop Behavior
<draft-bless-diffserv-le-phb-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 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.
Abstract
This document specifies properties and characteristics of a Limited
Effort (LE) per-hop behavior (PHB) for use within and between
Differentiated Services domains [1]. The primary objective of this
LE PHB is to protect best-effort (BE) traffic (packets forwarded
with the default PHB) from LE traffic in congestion situations,
i.e., when resources become scarce. In the latter case, best-effort
traffic preempts LE traffic up to a certain configurable level.
Depending on that configurable level, LE traffic may still get a
minimal share of bandwidth so that it will not be fully preempted by
best-effort traffic. There are numerous uses for this PHB, e.g., for
transmission of low precedence background traffic such as bulk data
transfers with low priority in time or transmission of traffic from
non-responsive sources.
Bless & Wehrle Expires: August 2001 [Page 1]
Internet-Draft Limited Effort PHB February 2001
Table of Contents
1 Purpose and Overview...........................................2
2 Description of LE per-hop behavior.............................5
2.1 Interaction with Other PHB Groups...........................5
2.2 Traffic Conditioning Actions................................8
2.3 Queueing and Discard Behavior...............................9
2.4 Recommended Codepoint for this PHB..........................9
2.5 Configuration and Management Issues.........................9
3 Security Considerations.......................................10
4 Tunneling.....................................................10
5 Implications on Services......................................10
6 Mapping to link-layer QoS mechanisms..........................10
7 Acknowledgments...............................................11
8 References....................................................11
9 Authors' addresses............................................12
1 Purpose and Overview
While Differentiated Services (DS) [1,5] will enable deployment of
qualitatively better services in the Internet, the current main
portion of traffic is up to now forwarded according to the best-
effort delivery principle. This "best-effort" (BE) service is still
adequate and sufficient for many applications. Even if some
applications will profit from future qualitatively better services,
some users may not want to pay the higher cost for those better
services and may prefer to use the common best-effort service
instead. However, there are many cases in which packets can be
forwarded with even lower precedence compared to best-effort packets.
If forwarding resources for packets of lower precedence are limited
by a configurable bound, best-effort service users will benefit from
this differentiation, because the impact of low precedence packets on
best-effort resources is limited. Therefore, the respective per-hop
forwarding behavior (PHB) defined in this document is called Limited
Effort (LE). Because this document defines properties of a forwarding
behavior within a node and requires only PHB mechanisms it actually
defines a PHB. However, this simple PHB can be deployed fast and will
Bless & Wehrle Expires: August 2001 [Page 2]
Internet-Draft Limited Effort PHB February 2001
be useful as long as a significant portion of traffic remains in the
BE class.
There are numerous possible uses for this PHB. One application
example is the transmission of low precedence background traffic
such as bulk data transfers with low priority in time. For instance,
transmission of backup data traffic during working hours or traffic
caused by web search engines while gathering information from web
servers. From this point of view it constitutes a network equivalent
to a background priority for processes in an operating system. A low
priority in time does not always imply that LE traffic is of minor
importance (backup data is surely important). For instance, when
using TCP for reliable data transfer it just means that this
transfer may last longer due to the more limited resources. Because
applications know the precedence of their packets, they may execute
an initial marking in DS aware end systems.
Another application example is protection of BE traffic from non-
responsive sources, i.e., such that do not respond to network
congestion situations. Especially, marking traffic of non-responsive
applications that demands a lot of resources for receiving this LE
PHB may effectively control its overall amount. Network providers
may prefer to assign even applications that would usually profit
from better qualitatively better services, such as multimedia
streaming, to receive this LE PHB. The reason for this policy may be
the effective protection of ordinary BE traffic due to the
configurable LE limit. As an example, Web radio traffic falls in
this category.
Moreover, an LE PHB is particularly useful in situations when
packets of a better service (something "above best-effort") are re-
marked by a node for subsequently receiving a forwarding treatment
that is nearly equivalent to the best-effort service. In this
situation the LE PHB helps to protect other best-effort packets from
experiencing unfair forwarding treatment, because it avoids their
preemption by re-marked packets. For instance, this case occurs when
heterogeneous multicast groups should be supported.
Changing a per-hop forwarding behavior of an incoming packet is
sometimes desired or even required, so that the packet is
subsequently forwarded with the lowest available priority. Usually,
this forwarding behavior would be equivalent to the Default PHB
resulting in a best-effort service. But, simply re-marking the DS
codepoint (DSCP) to the DSCP value of the Default PHB will probably
result in some unfair share of this re-marked traffic relating to
best-effort traffic. This is due to the fact that nearly all packets
that previously experienced a better service enter the behavior
aggregate (BA) of the Default behavior. Consequently, those re-marked
packets will preempt other incoming packets carrying a DSCP of the
Default PHB if not enough resources are available for the combined
traffic. This unfairness against existing best-effort traffic should
be avoided.
Bless & Wehrle Expires: August 2001 [Page 3]
Internet-Draft Limited Effort PHB February 2001
The basic concept behind the proposed Limited Effort per-hop behavior
is to discard those re-marked packets in a node more aggressively
than packets belonging to the default PHB if resources become scarce.
Merely discarding those packets more drastically in the re-marking
node is not sufficient, because currently there may be enough
resources available in this node, but maybe not in subsequent
downstream nodes. Therefore, this re-marked traffic of lower
precedence should be identifiable downstream by a separate codepoint.
For instance, a re-marking of packets is required when a receiver
joins a multicast group and does not want to or even is not able to
receive the currently used better service within this group (e.g.,
1 Mbit/s "Premium service"). Instead of this, the receiver wants to
get the traffic of this group without any quality of service
guarantee, i.e., basically a best-effort service. The node which
connects the new subtree of this receiver to the already existing
multicast delivery tree must therefore degrade the quality of service
of the incoming packet stream for replicated packets which are sent
downstream on the output link of the newly joined subtree (see Figure
1).
Moreover, specific excess traffic of any kind may be marked with the
LE codepoint. For example, this excess traffic could consist of
packets belonging to non-responsive flows (e.g., UDP flows). Thus,
other best-effort traffic (e.g., responsive TCP flows) is segregated
from this excess traffic, consequently not being adversely affected
by it.
|| Multicast Group Flow
|| 1 Mbit/s Premium service
\/
+---------+
| || |
| || |
| //\*) | *) Replicates are re-marked
+-//--\---+ with the LE PHB
// \
1 Mbit/s || |
Premium || | Limited Effort (LE)
Service \/ V
. \
. \
// \\ .
// \\ .
. . +---+
. . | R | New receiver wants no QoS
+---+
Figure 1: A new receiver without QoS requirements
joining a multicast group that uses Premium
service
Bless & Wehrle Expires: August 2001 [Page 4]
Internet-Draft Limited Effort PHB February 2001
The LE PHB solves the above-mentioned problems by discarding LE
packets more rigorously than those of the best-effort BA in case of
resource contention for residual bandwidth. Therefore limiting the
amount of packets in the LE class in relation to the amount of
packets in the best-effort class. This is described more detailed in
sections 2.1 and 2.3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
2 Description of LE per-hop behavior
In general, a Limited Effort per-hop forwarding behavior can be used
to protect traffic in the best-effort service class from unfairness
that otherwise would have been caused by those packets, which are now
in the LE. The latter packets may stem from excess traffic, non-
responsive traffic or re-marked traffic that has been experiencing a
better service before. Therefore, in order to restrict the impact of
those packets on packets in the Default PHB BA, the LE PHB provides
forwarding of IP packets with higher drop precedence than Default PHB
packets.
At first, it will not be necessary to have an LE PHB group comprising
more than one PHB, because within its BA, LE PHB essentially
resembles best-effort behavior that does not distinguish different
types of traffic (e.g., responsive and non-responsive flows), too.
However, as more experience is gained with this PHB it may become
necessary to provide two PHBs, one for responsive flows (e.g., TCP
flows and others that react to congestion in a TCP-like manner) and
one for non-responsive flows (e.g., UDP flows without congestion
control).
The Limited Effort per-hop behavior is intended for general use.
There may be many cases in which the LE PHB can be applied. Three of
them were already mentioned in section 1.
Using this PHB between two adjacent service providers is also useful,
because the upstream domain possibly had enough resources left to
carry the additional LE traffic volume, whereas the downstream domain
has not enough resources, therefore being in need of discarding some
portion of this traffic.
2.1 Interaction with Other PHB Groups
The LE PHB is essentially defined by its relation to the default PHB:
an LE packet is of minor relative importance compared to a best-
effort packet. Thus, in case of contention for bandwidth (i.e., a
congestion situation), packets receiving best-effort treatment
Bless & Wehrle Expires: August 2001 [Page 5]
Internet-Draft Limited Effort PHB February 2001
preempt packets of the LE behavior aggregate down to a certain share.
This share must be considerably lower than that of the best-effort
BA, but should not be equal to zero in order to retain a low portion
of LE traffic even when best-effort traffic takes up all available
residual bandwidth. Therefore, a minimum configured bandwidth share
for LE traffic exists as a lower bound that guarantees transport of
LE packets even in case of congestion. On the other hand, this bound
also constitutes an upper limit for the share of LE traffic during
congestion. This upper bound may be static, that is, fixed in
relation to the overall available bandwidth on a particular link (a
constant value for 100-Y in Figure 2), or it may be dynamic, i.e.,
fixed relative to the BE traffic share, thus variable in relation to
the overall available bandwidth, because BE traffic may consume
resources currently not used by other BAs (a dynamic value for Y that
depends on the amount of BE traffic; corresponding to a constant
ratio of (100-Y)/(100-X) in Figure 2).
0% X% Y% 100%
+----------------------------------------------------------------+
| Other BAs | Best-Effort | LE |
+----------------------------------------------------------------+
|<-Upper->|
| Bound |
Figure 2: Bandwidth share limits for LE traffic. Other
behavior aggregates (BA) currently use X% of
total available bandwidth, while best-effort
and LE traffic share the residual bandwidth.
If enough resources are available for other BAs and BE traffic, i.e.,
residual bandwidth exists that is not used by best-effort traffic, LE
packets may use more than the previously defined bound on their share
of total bandwidth, because this limit is only needed in case of
congestion (see Figure 3 and Figure 4). Therefore, any remaining
resources can be used to forward excess LE traffic, because all BE
demand is already met. In this case, there is no reason to discard
any of the LE packets until they exhaust the residual bandwidth,
because their presence does not adversely affect any of the best-
effort packets.
Bless & Wehrle Expires: August 2001 [Page 6]
Internet-Draft Limited Effort PHB February 2001
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 40% offered traffic
========================================| 40% upper bound
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 40% admitted traffic
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 45% offered traffic
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 45% admitted traffic
LLLLLLLLLLLLLLLLLLLLLLLLLLLL 28% offered traffic
==========| 10% upper bound
LLLLLLLLLLLLLLL 15% admitted traffic
--------------------------------------------------->
output link bandwidth
O: Other BAs, B: Best-Effort BA, L: LE BA
Figure 3: Other BAs fully exploit their allotted
resources, LE BA gets residual bandwidth that
best-effort doesn't use.
OOOOOOOOOOOOOOOOOOO 15% offered traffic
========================================| 40% upper bound
OOOOOOOOOOOOOOOOOOO 15% admitted traffic
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 55% offered
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 55% admitted
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 40% offered traffic
==========| 10% upper bound
LLLLLLLLLLLLLLLLLLLLLLLLLLLLL 30% admitted traffic
--------------------------------------------------->
output link bandwidth
O: Other BAs, B: Best-Effort BA, L: LE BA
Figure 4: Other BAs do not fully use their allotted
resources, best-effort utilizes unused
bandwidth of the other BAs, LE gets residual
bandwidth
The primary objective of the LE PHB is to segregate packets of the
best-effort behavior aggregate from packets that should receive a
less than best-effort treatment in case of congestion. This is
achieved by using higher drop precedence for LE packets than for
best-effort packets, thereby limiting the overall amount of LE
traffic in relation to the best-effort behavior aggregate (see Figure
5). Therefore, a congested node tries to protect best-effort packets
from being lost by preferably discarding LE packets.
Bless & Wehrle Expires: August 2001 [Page 7]
Internet-Draft Limited Effort PHB February 2001
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% offered traffic
========================================| 40% upper bound
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% admitted traffic
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 60% offered
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 54% admitted
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 40% offered traffic
==========| 10% upper bound
LLLLLLLLLLL 10% admitted traffic
--------------------------------------------------->
output link bandwidth
O: Other BAs, B: Best-Effort BA, L: LE BA
Figure 5: Other BAs do not fully use their allotted
resources, best-effort utilizes unused
bandwidth of the other BAs, LE is limited to
its specified upper bound.
With exception of the Default PHB, the LE PHB is entirely independent
of all other existing PHB specifications. Thus, any other PHB groups
may co-exist with the LE PHB in the same DS domain, because the LE
PHB does not preempt forwarding resources of other PHB groups.
If only a part of all packets belonging to a microflow are marked as
LE, the probability for reordering this microflow's packets may be
increased in dependence on the relation of the prior PHB to the LE
PHB and may depend on the actual implementation. However, because a
special relation to the Default PHB defines the LE PHB, it is
recommended that packets of a microflow are not reordered if they are
marked by codepoints associated with these two PHBs.
A realization of the LE PHB may use an already existing PHB of higher
drop precedence (e.g., AFx2 or AFx3 from an AF PHB group [3]), if its
actual implementation fulfills the requirements of this specification
(e.g., AFx1 is used for BE traffic).
2.2 Traffic Conditioning Actions
As for most other PHBs an initial classification and marking would
usually be performed at the first DS boundary node. In many cases,
packets may also be pre-marked in DS aware end systems by
applications due to their specific knowledge about the particular
precedence of packets.
Usually, the amount of LE traffic is implicitly limited by queueing
mechanisms and related discard actions of the PHB. Therefore, there
is normally no need to meter and police LE traffic explicitly.
Bless & Wehrle Expires: August 2001 [Page 8]
Internet-Draft Limited Effort PHB February 2001
However, a DS domain MAY control the amount of LE traffic that enters
or exits the domain, therefore (although not necessary) further
traffic conditioning actions MAY be applied.
2.3 Queueing and Discard Behavior
All packets of an arbitrary microflow that are marked for the LE PHB
MUST NOT be reordered. The dropping algorithm MUST treat all packets
within the LE BA identically, i.e., the discard rate of a particular
microflow's packets will be proportional to that flow's percentage of
the total amount of traffic with this LE BA.
It is recommended that LE packets use the same queue as best-effort
packets in order to avoid reordering of a microflow's packets that
are marked intermittently for receiving best-effort or LE forwarding
treatment.
One way to achieve the above objectives is to use a common queue for
best-effort and LE packets that is actively managed by a Random Early
Detection (RED) scheme [4]. A separate RED parameter set is managed
for each traffic type. If the "current" queue length (usually a
weighted average value) grows beyond a lower threshold, new arriving
LE packets for this queue are going to be dropped randomly with
increasing probability, until the queue length reaches an upper
threshold. Beyond this upper threshold every new incoming LE packet
for this queue is going to be discarded. If the threshold values for
LE packets are lower than those for best-effort packets, the RED
queue will start discarding LE packets earlier than BE packets.
However, there are many other possibilities of implementing the LE
PHB, and the given example is not to be understood as a prescription
for implementation. Other existing PHBs (e.g., an AF PHB) may also be
used for implementation, but must be configured in such a way that
the properties of the LE PHB defined in this document are satisfied.
2.4 Recommended Codepoint for this PHB
As long as this a PHB proposal, the temporary recommended code point
is taken from the experimental/local use (EXP/LU) portion of the
codepoint space. The recommended temporary codepoint is '000011' (see
section 3 of [5] for the meaning of this notation).
2.5 Configuration and Management Issues
There is no need for providing any resource-based admission control
mechanisms for this PHB. As described in section 2.1, a configurable
minimal bandwidth share, respectively upper bound exists for
bandwidth used by the LE BA if no residual bandwidth is left and all
other bandwidth is used for best-effort.
Bless & Wehrle Expires: August 2001 [Page 9]
Internet-Draft Limited Effort PHB February 2001
3 Security Considerations
Basically, the LE PHB causes no other security implications besides
the ones already mentioned in [5]. Because LE PHB provides a quality
that is even less compared to the usual best-effort delivery, there
is now one more possible PHB to reduce a packet's service.
On the other hand, there is currently no PHB providing a worse
service, so LE packets cannot be further reduced in service by re-
marking. Consequently, re-marking the inner header's codepoint of LE
packets at the egress of a tunnel with a codepoint of another PHB
would have only a positive effect on these packets. However, this
would possibly eliminate the primary objective of the LE and lead to
depletion of forwarding resources for other traffic streams in
congestion situations.
4 Tunneling
When LE packets are tunneled, the tunneling packets SHOULD also be
marked as LE.
5 Implications on Services
As described in section 2.1, traffic using the current best-effort
service should be segregated and protected from LE traffic in
congestion situations. Therefore, performance of the common best-
effort service is increased under those conditions.
6 Mapping to link-layer QoS mechanisms
In a shared medium LE traffic has a very good counterpart in the
link-layer QoS mechanisms as defined by IEEE 802.1p: the background
traffic type. Therefore, packets carrying a DSCP value of the LE PHB
can be mapped to 802.1p background traffic priority, i.e., setting
the "user_priority" field to value 1 in all link-layer frames that
carry a part of an LE packet as payload. In order to achieve a real
support for LE packets, link-layer frames containing best-effort
packets should use the default user_priority of 0 for indicating
traffic type "Best Effort".
LE packets within a switched link-layer could also use available
means to indicate higher drop precedence for LE packets. For
instance, when using ATM as link-layer, the value encoded in the Cell
Loss Priority (CLP) field of the ATM cell header [6] may be set to 1
in all ATM cells carrying a part of an LE packet as payload, whereas
cells carrying a part of a best-effort packet as payload should use a
CLP value of 0.
Bless & Wehrle Expires: August 2001 [Page 10]
Internet-Draft Limited Effort PHB February 2001
As another example, when using Frame Relay as link-layer, the Discard
Eligibility Indicator (DE) bit can be set to 1 for frames containing
an LE packet as payload, indicating that this frame should be
discarded in preference to other frames in a congestion situation
[7]. All frames carrying a part of a best-effort packet as payload
should use a DE bit value of 0.
7 Acknowledgments
Thanks to Jochen Schiller for discussion of the LE PHB.
8 References
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
An Architecture for Differentiated Services. RFC 2475, Dec.
1998.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, Mar. 1997
[3] F. Baker, J. Heinanen, W. Weiss, and J. Wroclawski. Assured
Forwarding PHB Group. RFC2597, Jun. 1999
[4] S. Floyd and V. Jacobson. Random Early Detection Gateways for
Congestion Avoidance. IEEE/ACM Transactions on Networking,
Vol. 1(4):397--413, Aug. 1993
[5] F. Baker, D. Black, S. Blake, and K. Nichols. Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers. RFC 2474, Dec. 1998.
[6] ITU-T. B-ISDN ATM Layer Specification. ITU-T Recommendation
I.361, 11/1995
[7] ITU-T. ISDN Data Link Layer Specification for Frame Mode Bearer
Services. ITU-T Recommendation Q.922, 1992
Bless & Wehrle Expires: August 2001 [Page 11]
Internet-Draft Limited Effort PHB February 2001
9 Authors' addresses
Comments and questions related to this draft can be addressed to one
of the authors listed below.
Roland Bless
Institute of Telematics
Universitaet Karlsruhe (TH)
Zirkel 2
D-76128 Karlsruhe
Germany
Tel.: +49 721 608 6396
bless@telematik.informatik.uni-karlsruhe.de
Klaus Wehrle
Institute of Telematics
Universitaet Karlsruhe (TH)
Zirkel 2
D-76128 Karlsruhe
Germany
Tel.: +49 721 608 6414
wehrle@telematik.informatik.uni-karlsruhe.de
Bless & Wehrle Expires: August 2001 [Page 12]